Just-In-Time Access

Standing privileges are one of the largest attack surfaces in any organization. Service accounts with persistent credentials, API keys that never expire, and bot tokens with broad scopes create opportunities for credential theft, lateral movement, and privilege escalation. VeraID’s Just-In-Time (JIT) access model eliminates standing privileges by creating credentials on demand, scoping them to the minimum required access, and automatically revoking them when the task is complete or the time window expires.

Zero Standing Privileges

The principle behind JIT access is simple: no identity should hold credentials that it does not actively need. Instead of provisioning long-lived credentials and hoping they get rotated, VeraID creates short-lived, narrowly scoped credentials at the moment they are needed and destroys them the moment they are not.

Benefits of zero standing privileges:

• Reduced blast radius — Compromised credentials expire automatically, limiting the window of exposure
• Audit clarity — Every credential is tied to a specific request, approval, and time window
• Compliance alignment — Meets SOC 2 CC6.1 (logical access), PCI-DSS 7.2 (least privilege), and HIPAA access management requirements
• Operational hygiene — No stale credentials to discover, rotate, or decommission

Tip

JIT access is most impactful for CI/CD pipelines, deployment automation, and AI agents — identities that need elevated access for short, well-defined tasks and should not hold persistent credentials between runs.

---

JIT Access Flow

┌──────────┐    request     ┌──────────┐    approve     ┌──────────┐    use       ┌──────────┐
│          │───────────────►│          │───────────────►│          │────────────►│          │
│ Identity │                │ VeraID   │                │ Credential│             │ Resource │
│          │◄───────────────│          │◄───────────────│ Issued   │────────────►│          │
│          │   credential   │          │   auto-expire  │          │   expires   │          │
└──────────┘                └──────────┘                └──────────┘             └──────────┘

1. Request — An identity (or its automation) requests temporary access to a specific resource or set of scopes
2. Approve — The request is evaluated against auto-approval rules or routed to a human reviewer
3. Grant — A temporary credential is created with the requested scopes and a defined TTL
4. Use — The identity uses the credential to access resources within the granted scopes
5. Expire — The credential automatically expires at the end of its TTL, or is revoked manually if the task completes early

---

Creating JIT Credentials

Direct JIT Credential

Create a JIT credential directly when auto-approval is sufficient and no human review is needed.

curl -X POST https://app.veraid.io/api/v1/credentials/jit \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identityId": "idt_9c3a8b7e-4f21-4d6a-b8e1-a2c5d9f07e3b",
    "name": "deploy-staging-20260319",
    "scopes": ["deploy:staging", "read:config"],
    "duration": "2h",
    "maxUsage": 10
  }'

Field	Type	Required	Description
identityId	string	Yes	The identity that will use this credential
name	string	Yes	Human-readable name for audit trail
scopes	string[]	Yes	Access scopes granted to this credential
duration	string	Yes	TTL in the format \d+[smhd] (seconds, minutes, hours, days)
maxUsage	integer	No	Maximum number of times the credential can be used. Null for unlimited within TTL

Duration examples:

Pattern	Duration
30s	30 seconds
15m	15 minutes
2h	2 hours
1d	1 day

Response:

{
  "id": "cred_jit_7f8a9b2c-3d4e-5f6a-b7c8-d9e0f1a2b3c4",
  "key": "kd_jit_abc123def456ghi789jkl012mno345pqr678",
  "name": "deploy-staging-20260319",
  "type": "JIT",
  "status": "ACTIVE",
  "scopes": ["deploy:staging", "read:config"],
  "maxUsage": 10,
  "usageCount": 0,
  "issuedAt": "2026-03-19T14:30:00Z",
  "expiresAt": "2026-03-19T16:30:00Z",
  "identityId": "idt_9c3a8b7e-4f21-4d6a-b8e1-a2c5d9f07e3b"
}

Danger

The key field is returned only once at creation time. Store it securely immediately — VeraID does not retain the plaintext key after issuance. If lost, the credential must be revoked and a new one created.

JIT Credential Format

JIT credentials follow the VeraID credential format with a jit environment prefix:

kd_jit_{random}

This prefix allows secret scanning tools, WAFs, and log analysis systems to immediately identify JIT credentials and distinguish them from long-lived production (kd_live_*) or test (kd_test_*) credentials.

---

JIT Requests with Approval

For operations that require human review, submit a JIT request that enters an approval workflow before the credential is issued.

curl -X POST https://app.veraid.io/api/v1/jit-requests \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identityId": "idt_9c3a8b7e-4f21-4d6a-b8e1-a2c5d9f07e3b",
    "reason": "Emergency hotfix deployment to production - JIRA-4521",
    "scopes": ["deploy:production", "write:config", "read:secrets"],
    "resources": ["prod:api-gateway", "prod:config-store"],
    "duration": 3600
  }'

Field	Type	Required	Description
identityId	string	Yes	The identity requesting access
reason	string	Yes	Business justification for the access request
scopes	string[]	Yes	Requested access scopes
resources	string[]	No	Specific resources to be accessed
duration	integer	Yes	Requested TTL in seconds (60 to 604800 — 1 minute to 7 days)

JIT Request Status Lifecycle

┌──────────┐    approve     ┌──────────┐     use       ┌──────────┐
│ PENDING  │───────────────►│ APPROVED │──────────────►│ EXPIRED  │
│          │                │          │               │          │
└────┬─────┘                └────┬─────┘               └──────────┘
     │                           │
     │  reject                   │  revoke
     ▼                           ▼
┌──────────┐               ┌──────────┐
│ REJECTED │               │ REVOKED  │
└──────────┘               └──────────┘

Status	Description
PENDING	Request submitted and awaiting approval
APPROVED	Request approved; JIT credential issued and active
REJECTED	Request denied by a reviewer
EXPIRED	Credential TTL has elapsed; access automatically revoked
REVOKED	Credential manually revoked before TTL expiration

---

Auto-Approval Rules

Auto-approval rules allow JIT requests to be granted automatically when they meet predefined conditions, eliminating the latency of human review for low-risk, routine operations.

{
  "autoApprovalRules": [
    {
      "name": "staging-deploy-auto-approve",
      "conditions": {
        "resources": ["staging:*"],
        "maxDuration": 7200,
        "maxScopes": ["deploy:staging", "read:config"],
        "identityRiskScore": { "max": 30 },
        "identityTags": ["ci-cd"]
      },
      "enabled": true
    },
    {
      "name": "read-only-auto-approve",
      "conditions": {
        "scopes": ["read:*"],
        "maxDuration": 3600,
        "identityRiskScore": { "max": 20 }
      },
      "enabled": true
    }
  ]
}

A JIT request is auto-approved when all conditions in at least one matching rule are satisfied. If no rule matches, the request enters the standard approval workflow.

Condition	Description
resources	Requested resources must match these patterns
maxDuration	Requested duration must not exceed this value (seconds)
maxScopes	Requested scopes must be a subset of these scopes
identityRiskScore.max	Identity’s current risk score must be at or below this threshold
identityTags	Identity must have all specified tags

Note

Auto-approval rules are evaluated in order. The first matching rule is applied. If you need different approval behavior for overlapping conditions, order your rules from most specific to least specific.

---

Break-Glass Emergency Access

In critical incidents, standard approval workflows may be too slow. VeraID provides a break-glass mechanism that grants immediate emergency access with enhanced logging and mandatory post-incident review.

curl -X POST https://app.veraid.io/api/v1/jit-requests/break-glass \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identityId": "idt_9c3a8b7e-4f21-4d6a-b8e1-a2c5d9f07e3b",
    "reason": "P0 production outage - all payment processing halted",
    "scopes": ["admin:production"],
    "resources": ["prod:*"],
    "duration": 1800,
    "incidentId": "INC-2026-0319-001"
  }'

Break-glass access differs from standard JIT in several ways:

• No approval required — Credential is issued immediately
• Enhanced audit logging — Every action taken with the credential is logged with full request/response bodies
• Mandatory review — A post-incident review task is automatically created and assigned to the security team
• Alert escalation — Notifications are sent to security leadership, the identity’s owner, and configured incident channels
• Short TTL — Maximum duration is capped at 4 hours (14400 seconds)

Caution

Break-glass access bypasses approval workflows by design. Misuse is logged and flagged for review. Organizations should define clear policies for when break-glass access is appropriate and ensure all break-glass events are reviewed within 24 hours.

---

SDK Integration

import { VeraIDClient } from '@veraid/sdk';

const client = new VeraIDClient({
  apiKey: process.env.VERAID_API_KEY,
  agentId: process.env.VERAID_AGENT_ID,
});

// Request JIT access
const jitRequest = await client.jit.request({
  reason: 'Scheduled database migration - JIRA-4590',
  scopes: ['write:database', 'read:config'],
  resources: ['prod:analytics-db'],
  duration: 3600,
});

// Check status (auto-approved requests return immediately)
if (jitRequest.status === 'APPROVED') {
  const credential = jitRequest.credential;
  console.log(`JIT credential issued: ${credential.id}`);
  console.log(`Expires at: ${credential.expiresAt}`);

  // Use the credential
  // ...

  // Revoke early when done
  await client.jit.revoke(jitRequest.id, {
    reason: 'Migration complete',
  });
}

---

What’s Next

• Attestation Campaigns — Review and certify identity access on a recurring basis
• Compliance — Map JIT access controls to SOC 2, HIPAA, and PCI-DSS requirements
• Policy Overview — Define PBAC policies that govern JIT credential scopes