Why Risk Context Is the Key to Just-in-Time Privileged Access That Scales

In September 2026, federal auditors found that anyone on the U.S. Customs and Border Protection network could operate a highly privileged service account. The issue encompassed more than 76,000 people, and any of them could have reset other users’ passwords and taken over accounts with access to law enforcement and biometric data.

Auditors reported no breach, and CBP has since pulled the access. The finding still shows what standing privilege looks like at scale: powerful rights, held by default, far beyond the people who need them.

Just-in-time (JIT) privileged access was built to remove standing privileges like these. It grants elevated rights only for approved work, then takes them back. Time limits alone wouldn’t have closed CBP’s gap, though. Someone still has to decide who should be able to ask. At scale, JIT runs into its own problems. Longer access windows ease the pressure but slowly bring back the standing privilege JIT was meant to remove. Risk context is the better fix. It’s what the system can verify about a request: who’s asking, from which device, for which target, how sensitive that target is, and whether an approved task backs it.

Those signals separate requests that can proceed under established rules from those that need a closer look. They also set how much access each one is granted.

Risk Context Keeps Access Moving at the Speed of the Work

Take this scenario as an example. A release engineer is preparing to restart a development server after a scheduled deployment. The request comes from the engineer’s usual account on a managed device, and the change has already been approved. Another manual sign-off may add little value if the system can verify those details. Risk-driven just-in-time privileged access can be configured to evaluate the request automatically. If approved, JIT grants only the permissions required for the restart and only for a limited period.

But the stakes change if the same engineer requests access to a production database with customer records, even from the same device and account. That request should require stronger authentication or a review by the database owner. Approval should rest on information the system can verify. A maintenance ticket, for example, should match an approved task on the server being accessed. A ticket number by itself? That proves nothing.

The signals need scrutiny too. An attacker who takes over the engineer’s account and laptop inherits the same “usual account, managed device” profile. Signals should reduce friction for low-impact work, not replace authentication. Anything that could do real damage should still trigger step-up checks, whoever appears to be asking.

Automation removes the approver entirely. A deployment pipeline running an unattended release can’t wait for a person to approve each step, and neither can many service accounts and AI agents. Here, the context comes from the workload: its identity, the job it runs, and the environment it targets. A pipeline deploying an approved build to staging can proceed. The same pipeline reaching for production secrets outside a release should not.

Managed identities and short-lived credentials can provide controlled access where supported. Some workloads still need continuing permissions with narrow scope. Every automated identity needs a named owner. Higher-risk exceptions need a clear route to human review.

Risk Context Aligns Every Elevation With the Task at Hand

Temporary access can still be too much. Full admin rights on a production database for five minutes can do more damage than read-only access to the same database for an hour. Duration is only part of the story. The potential damage depends on how far the account can reach and what it can do. Risk context should set that reach: the more sensitive the target, the narrower the default grant. CBP’s service account was the reverse, with sweeping rights open to an entire workforce.

Say an engineer needs to correct one service configuration. If the platform supports finer-grained roles, the grant can be limited to that service and the change required. It doesn’t need control over the whole server. A database migration may justify broader permissions. But the approved environment and maintenance window should still set boundaries. JIT should ideally work alongside the broader principle of least privilege.

Context can also change after someone is admitted. Commands unrelated to the maintenance task might trigger alerts, require extra authentication, or warrant investigation. Whether they can trigger immediate termination depends on the monitoring tools and enforcement available on the target system.

A JIT approval engine alone shouldn’t be assumed to inspect commands or end an active session. Teams deploying these controls should ask what is actually enforced, and at which point in the connection.

Expiration needs the same scrutiny. When a JIT window closes, the role assignment ends, but that doesn’t always end the access. An application may still honor a session the user opened earlier. The dashboard shows access revoked while the user is still working. That’s why it’s important to test expiration on the system being protected, not just in the access tool. Open a session, let the window close mid-task, and check whether the user can keep going.

Risk Context Makes Every Approval Mean Something

A manager who has to approve a routine request over and over may stop looking closely at the next one. Attackers already exploit this habit. In MFA fatigue attacks, they flood users with push prompts until someone taps Approve.

Fatigue is one of the quieter costs of making every privileged action a manual exception. Approval queues grow, but the attention available for each request doesn’t. Automating well-understood, low-risk cases gives reviewers more time for decisions where the consequences are genuinely uncertain.

An escalation should contain enough detail to support a judgment. If an administrator wants access to a production database outside the maintenance window, the reviewer needs to understand the work and why it can’t wait. The approved ticket, if any, should relate to the requested role. A request that exceeds the scope of the work can be narrowed before it is granted.

The same context should survive in the audit record. Logging who clicked Approve establishes a sequence of events, but it doesn’t explain whether the permission was justified. A more useful record connects the request with the policy decision and the scope actually granted. It should also show when access was removed, to the extent the platform can verify that outcome. Investigators can then tell a real emergency change from activity that merely used an approved account.

Reviewing these records may reveal uncomfortable patterns. If administrators routinely request extensions, the approved windows may not fit the work. If certain users repeatedly override automated decisions, the underlying policy may be poorly designed or the input data unreliable. The feedback should lead to changes in the rules and, where necessary, in the systems supplying the context.