Documentation

Zero Standing Privilege

Eliminate persistent access by granting permissions just-in-time, for exactly as long as needed, with automatic revocation.

What is Zero Standing Privilege?

Zero Standing Privilege (ZSP) is a security model where identities have no permanent access to sensitive resources. Instead, access is granted on-demand for a limited time window, then automatically revoked.

Traditional access control gives users persistent permissions that remain active 24/7, even when not needed. This creates a large attack surface - if credentials are compromised, an attacker has immediate access. ZSP reduces this risk by ensuring permissions exist only when actively required for a specific task.

Traditional Access

  • ✗Permissions granted indefinitely
  • ✗Active 24/7, even when not in use
  • ✗Manual revocation required
  • ✗Large attack surface

Zero Standing Privilege

  • ✓Just-in-time access grants
  • ✓Time-bound sessions (minutes to hours)
  • ✓Automatic expiration and revocation
  • ✓Minimal attack surface

How TigerIdentity Implements ZSP

TigerIdentity's ZSP implementation is built on three core mechanisms:

1. Just-in-Time Access Grants

Users request access to specific resources for a specific duration. The policy engine evaluates the request and, if approved, provisions temporary credentials or elevates permissions.

  • Request includes resource, action, and duration
  • Optional approval workflow for sensitive resources
  • Credentials provisioned directly to target system

2. Session Management & Tracking

Every access grant creates a tracked session with metadata: who, what, when, and why. Sessions are monitored in real-time for anomalous behavior.

  • Sessions stored in Redis for fast lookup
  • Real-time activity monitoring and anomaly detection
  • Manual revocation supported via API or UI

3. Automatic Expiration & Revocation

When the session TTL expires, TigerIdentity automatically removes credentials or revokes permissions in the target system. No manual cleanup required.

  • Guaranteed expiration even if user doesn't log out
  • Grace period for active operations (configurable)
  • Notification sent before and after expiration

JIT Access Flow

Here's a complete example of requesting, approving, and using just-in-time access:

1
Request Access

# User requests 2-hour access to production database
curl -X POST https://api.tigeridentity.com/v1/access/request \
  -H "Authorization: Bearer ${USER_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "resource": {
      "type": "database",
      "id": "db:prod-customer-db"
    },
    "actions": ["read", "query"],
    "duration": "2h",
    "reason": "Investigating customer support ticket #12345"
  }'

# Response
{
  "request_id": "req_abc123",
  "status": "pending_approval",
  "requires_approval": true,
  "approvers": ["manager", "data-governance"],
  "expires_at": "2026-02-05T11:00:00Z"
}

2
Approval (if required)

# Manager approves the request
curl -X POST https://api.tigeridentity.com/v1/access/approve \
  -H "Authorization: Bearer ${MANAGER_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "req_abc123",
    "decision": "approve",
    "comment": "Approved for customer support investigation"
  }'

# Response
{
  "request_id": "req_abc123",
  "status": "approved",
  "approved_by": "user:[email protected]",
  "approved_at": "2026-02-05T09:05:00Z"
}

3
Grant Access

# TigerIdentity provisions temporary credentials
# This happens automatically after approval

# User retrieves credentials
curl -X GET https://api.tigeridentity.com/v1/access/credentials/req_abc123 \
  -H "Authorization: Bearer ${USER_TOKEN}"

# Response
{
  "session_id": "sess_xyz789",
  "credentials": {
    "type": "postgresql",
    "host": "prod-db.company.internal",
    "port": 5432,
    "database": "customers",
    "username": "temp_jdoe_20260205",
    "password": "generated_temp_password_xyz"
  },
  "expires_at": "2026-02-05T11:10:00Z",
  "permissions": ["SELECT", "EXPLAIN"],
  "time_remaining": "1h 59m 30s"
}

4
Use Access

User connects to the database with temporary credentials. All queries are logged and monitored for anomalies.

5
Automatic Revocation

After 2 hours, TigerIdentity automatically deletes the temporary database user and revokes all permissions. The session is marked as expired.

Configuration & Session Policies

Configure ZSP behavior for different resource types and contexts:

# zsp-config.yaml
apiVersion: tigeridentity.com/v1
kind: ZSPConfig
metadata:
  name: production-zsp-policy
spec:
  # Default session settings
  defaults:
    max_duration: 4h
    default_duration: 1h
    warning_before_expiry: 10m
    grace_period_for_active_operations: 5m

  # Resource-specific settings
  resources:
    - type: database
      environment: production
      settings:
        max_duration: 2h
        require_approval: true
        require_reason: true
        approvers:
          - type: manager
          - type: group
            name: data-governance
        approval_timeout: 1h

    - type: aws_role
      tags:
        sensitivity: high
      settings:
        max_duration: 30m
        require_approval: true
        require_mfa: true
        max_concurrent_sessions: 1

    - type: kubernetes_namespace
      environment: production
      settings:
        max_duration: 4h
        require_approval: false  # Auto-approve for on-call engineers
        require_reason: true
        conditions:
          - require:
              subject.groups: [on-call, sre-team]

  # Renewal settings
  renewal:
    enabled: true
    max_renewals: 2
    renewal_window: 10m  # Can renew within 10m of expiration
    require_reapproval: false

  # Monitoring and alerting
  monitoring:
    alert_on_long_sessions: true
    long_session_threshold: 3h
    alert_on_multiple_renewals: true
    alert_on_unusual_access_patterns: true

  # Automatic revocation triggers
  revocation_triggers:
    - event_type: caep.risk_score_high
    - event_type: caep.device_compliance_change
      when:
        new_status: non_compliant
    - event_type: identity.group_membership_changed
      when:
        removed_from: [engineering, on-call]

Break-Glass Procedures

For emergencies when normal approval workflows would be too slow, TigerIdentity supports break-glass access with enhanced auditing and notification.

When to Use Break-Glass

Break-glass should only be used for genuine emergencies: production outages, security incidents, or critical business needs. All break-glass sessions are logged, audited, and reviewed.

Break-Glass Features

  • Immediate access without approval
  • Shorter max duration (typically 30-60 minutes)
  • Requires detailed justification
  • Real-time alerts to security team
  • Enhanced activity logging
  • Automatic post-incident review

Break-Glass Request

curl -X POST \
  https://api.tigeridentity.com/v1/access/break-glass \
  -H "Authorization: Bearer ${TOKEN}" \
  -d '{
    "resource": "db:prod-customer-db",
    "actions": ["read", "write"],
    "duration": "30m",
    "emergency_reason": "Production outage - customer data corruption detected. Need immediate access to restore from backup.",
    "incident_id": "INC-12345"
  }'

Monitoring & Audit

Every ZSP session is fully audited with comprehensive logging of all access requests, approvals, usage, and revocations.

Logged Events

  • Access request created
  • Approval/denial with approver identity
  • Credentials provisioned
  • Session activity (queries, operations)
  • Session renewal attempts
  • Manual or automatic revocation
  • Break-glass access

Audit Reports

  • Access request history by user
  • Resource access patterns over time
  • Approval bottlenecks and timeouts
  • Break-glass usage summary
  • Session duration analytics
  • Compliance reports for SOC2/ISO27001

Best Practices

Start with high-privilege resources

Implement ZSP first for production databases, admin roles, and sensitive systems. Gradually expand to more resources as the team adapts.

Set reasonable default durations

Most tasks require 1-2 hours of access. Set max durations based on actual usage patterns, not worst-case scenarios.

Use approval workflows selectively

Require approval for the most sensitive resources, but auto-approve routine access for trusted teams (e.g., on-call engineers).

Monitor and alert on anomalies

Alert on unusual patterns: frequent break-glass access, long sessions, access outside business hours, or requests from terminated users.

Document break-glass procedures

Ensure all team members know when and how to use break-glass access. Review all break-glass sessions in post-incident reviews.

Related Documentation

Policy Engine

Write policies that trigger JIT access workflows based on context.

CAEP Integration

Automatically revoke sessions when security events indicate risk.

API Reference

Complete API documentation for access requests and session management.

Implement Zero Standing Privilege

Eliminate persistent access and reduce your attack surface with just-in-time permissions.

Start Free TrialBook a Demo