Just-in-Time Access and Zero Trust Identity

The traditional model of access management gives people permissions and hopes they use them responsibly. Just-in-Time access and Zero Trust reject that model entirely. JIT says no one should have standing access to anything sensitive — you get access when you need it, for exactly as long as you need it, and it disappears automatically. Zero Trust says the network you are on is irrelevant — every request is authenticated and authorized based on identity, device, and context, regardless of whether you are in the office or on a coffee shop Wi-Fi.

Together, these two principles are reshaping how organizations think about access control. As a GRC Engineer, you need to understand them well enough to evaluate whether an organization's implementation is substantive or performative.

Just-in-Time access

The principle

Just-in-Time access eliminates standing privileges. No one has permanent admin access. No one has always-on production database credentials. Instead, access is granted only when needed, for only as long as needed, and automatically revoked when the time window expires.

The shift from standing access to JIT access is the single most impactful change an organization can make to reduce the blast radius of a compromised credential. If an attacker steals a developer's credentials and that developer has permanent production admin access, the attacker has production admin access. If the developer has JIT access and the role is not currently activated, the stolen credential gives the attacker nothing beyond the developer's baseline (non-privileged) permissions.

JIT patterns

There are four common patterns for implementing JIT access in enterprise environments:

Time-boxed role activation — A user requests activation of a privileged role for a specified duration. Azure PIM is the canonical example: an engineer activates the "Global Administrator" role for four hours, performs the necessary work, and the role deactivates automatically when the window expires. If they forget, the system handles it.

Approval-based access — Access requests go through an approval workflow before activation. A common implementation: a user requests production database access via a Slack bot, the request routes to their manager and the database owner, one or both approve, and the user receives temporary credentials valid for two hours. Tools like ConductorOne, Indent, and Abbey automate this flow.

Ephemeral credentials — Instead of granting access to an existing permanent credential, the system generates a short-lived credential on demand. AWS STS AssumeRole with a session duration of one hour, HashiCorp Vault dynamic database credentials that expire after 30 minutes, and temporary SSH certificates that are valid for a single session are all examples. The credential itself has an expiration built in — there is nothing to revoke because the credential stops working on its own.

Break-glass with alerts — Emergency access that bypasses normal approval workflows but triggers immediate notifications. When an engineer activates a break-glass account, the security team is paged, the session is recorded, and a post-incident review is mandatory. Break-glass accounts exist for scenarios where the approval workflow itself is unavailable (IdP outage, for example) or where waiting for approval would cause a customer-impacting incident to escalate.

Benefits of JIT

• Reduced blast radius — If a credential is compromised, the attacker only has access during the narrow windows when the role is activated. Most of the time, there is nothing to exploit.
• Smaller attack window — Standing access is a 24/7 target. JIT access is a target only during the minutes or hours the role is active.
• Automatic cleanup — No need for manual revocation. Time-boxed access expires automatically, eliminating the privilege creep that plagues traditional access models.
• Audit trail of every activation — Every JIT request records who requested access, why, who approved it, when it was activated, and when it expired. This is exactly the evidence auditors look for.

Implementation challenges

JIT access is not free of friction. These are the real-world challenges you will encounter:

• On-call access — Engineers on call need immediate access to production systems when an incident occurs. Waiting for manager approval at 3 AM is not viable. The solution is pre-approved on-call roles that activate automatically when the engineer is on the on-call rotation, with session recording and post-hoc review.
• Automated pipelines — CI/CD pipelines and automated processes need consistent access to deploy code, run migrations, and manage infrastructure. Service accounts for pipelines typically use ephemeral credentials (short-lived tokens issued per pipeline run) rather than human-style JIT approval flows.
• Legacy systems — Some systems do not support temporary credentials, role activation APIs, or session duration limits. For these systems, the JIT implementation may involve a credential vault that checks out a permanent credential for a limited time and rotates it after check-in, layering JIT semantics on top of a system that does not natively support them.

Zero Trust identity

The core principles

Zero Trust is an architectural approach defined in NIST SP 800-207 that eliminates the concept of a trusted network. The four core principles:

• Never trust, always verify — No request is trusted by default, regardless of where it originates. A request from inside the corporate network receives the same scrutiny as a request from a public coffee shop.
• Assume breach — Design systems as if an attacker is already inside the network. This means every system enforces its own access controls rather than relying on the network perimeter to keep attackers out.
• Least privilege — Every identity gets the minimum access required to perform its function. No broad permissions, no "just in case" access, no inherited admin rights.
• Verify explicitly — Access decisions are based on all available data: identity, device health, location, behavior patterns, resource sensitivity, and time of access.

Identity as the new perimeter

In the traditional model, the network perimeter was the trust boundary. If you were inside the corporate network (physically in the office or connected via VPN), you were trusted. Firewalls kept attackers out, and once inside, lateral movement was relatively unconstrained.

This model is broken. Cloud infrastructure, remote work, SaaS applications, and mobile devices mean that the "inside" of the network no longer exists as a meaningful security boundary. An employee accessing AWS from their home office, a contractor accessing Google Workspace from a personal laptop, and a CI/CD pipeline calling an API from a cloud VM are all "outside" the traditional perimeter.

In a Zero Trust model, identity replaces the network as the primary trust boundary. Every request — regardless of network location — must be authenticated (who is making this request?), authorized (does this identity have permission for this action?), and evaluated against a set of contextual signals before access is granted.

TRADITIONAL MODEL                        ZERO TRUST MODEL
─────────────────                        ─────────────────

┌─────────────────────────┐              Every request, regardless of origin:
│     Corporate Network   │
│  ┌─────┐  ┌─────┐      │              ┌────────────┐
│  │ App │  │ DB  │      │              │  Identity   │──── Who are you?
│  └─────┘  └─────┘      │              │  verified   │     (phishing-resistant MFA)
│                         │              └─────┬──────┘
│  Inside = Trusted       │                     │
│  Free lateral movement  │              ┌─────▼──────┐
└────────────┬────────────┘              │  Device     │──── Is device managed
             │                           │  trust      │     and compliant?
        ┌────┴────┐                      └─────┬──────┘
        │Firewall │                             │
        └────┬────┘                      ┌─────▼──────┐
             │                           │  Context    │──── Location, time,
        Outside = Untrusted              │  evaluated  │     behavior, risk score
                                         └─────┬──────┘
                                                │
                                         ┌─────▼──────┐
                                         │  Policy     │──── Allow / Deny /
                                         │  engine     │     Step-up auth
                                         └────────────┘

Key components

Strong authentication — Zero Trust requires phishing-resistant MFA. Passwords alone are insufficient, and even TOTP-based MFA is vulnerable to adversary-in-the-middle attacks. FIDO2 hardware keys or passkeys are the standard for Zero Trust environments.

Device trust — Authentication is not enough. The device making the request must also be evaluated. Is it a managed device enrolled in MDM? Is the OS patched? Is disk encryption enabled? Is endpoint detection running? A valid user on a compromised device is still a threat.

Continuous verification — Traditional authentication is a one-time event at login. Zero Trust evaluates access continuously throughout the session. If a device's compliance status changes mid-session, or if the user's behavior deviates from baseline, access can be stepped up (require re-authentication) or revoked in real time.

Microsegmentation — Instead of a flat network where any system can reach any other system, microsegmentation creates fine-grained network boundaries around individual workloads. Even if an attacker compromises one server, they cannot move laterally to other servers because each segment has its own access policies.

NIST 800-207 Zero Trust Architecture

NIST SP 800-207 defines the reference architecture for Zero Trust with three core components:

• Policy Engine (PE) — The decision-maker. It evaluates access requests against policy rules, identity attributes, device trust signals, and contextual data to make allow/deny decisions.
• Policy Administrator (PA) — The enforcer. It takes the Policy Engine's decision and configures the appropriate enforcement points to grant or deny access. It establishes and terminates sessions.
• Policy Enforcement Point (PEP) — The gatekeeper. It sits between the subject (user/device) and the resource (application/data) and enforces the Policy Administrator's decisions. No traffic reaches the resource without passing through the PEP.

Real-world implementations

• Google BeyondCorp — The original Zero Trust implementation. Google eliminated VPN entirely and moved all internal applications behind an access proxy that evaluates identity and device trust for every request. Published in 2014 and battle-tested at Google scale.
• Microsoft Zero Trust — Built on Azure AD Conditional Access, Intune (device management), and Microsoft Defender. Conditional Access policies evaluate identity, device compliance, location, and risk score before granting access to Microsoft 365 and Azure resources.
• Zscaler Zero Trust Exchange — A cloud-native proxy that brokers connections between users and applications. Users never connect directly to the corporate network — Zscaler mediates every connection and applies identity and device policies.

What to carry forward

JIT access and Zero Trust are the direction the industry is moving. Standing access is being replaced by time-bounded, approval-gated access that expires automatically. Network-perimeter trust is being replaced by identity-centric, context-aware access decisions that evaluate every request independently.

In the next exercise, you will design an access review program and JIT access workflow for a real-world scenario — putting the PAM, IGA, JIT, and Zero Trust concepts from these two lessons into practice.