Documentation / Guides

Implement Zero Standing Privilege

A complete guide to eliminating permanent access and implementing Just-in-Time (JIT) access

What is Zero Standing Privilege?

Zero Standing Privilege (ZSP) is a security model where users have no permanent access to sensitive resources. Instead, access is granted just-in-time (JIT) when needed, approved through workflows, and automatically revoked after a time limit.

Benefits of ZSP

✓Reduced Attack Surface: No credentials to steal when not in use
✓Improved Compliance: Automatic access expiration and audit trails
✓Better Accountability: Know exactly who accessed what and why
✓Insider Threat Protection: Limits lateral movement and privilege abuse

Timeline

Recommended Duration: 2-4 weeks for initial rollout to production systems
Effort: 1-2 security engineers, part-time collaboration from app teams

1

Audit Current Access

Discover all standing privileges in your environment

Start by understanding what permanent access exists today. Connect TigerIdentity to your infrastructure to automatically discover standing privileges.

Connect Your Systems

# connectors/aws-connector.yaml
apiVersion: v1
kind: Connector
metadata:
  name: aws-production
spec:
  type: aws
  config:
    role_arn: arn:aws:iam::123456789:role/TigerIdentityReader
    regions: [us-east-1, us-west-2]
    sync_interval: 1h

  # What to discover
  resources:
    - iam_users
    - iam_roles
    - ec2_instances
    - rds_databases
    - s3_buckets

Run Discovery Report

# Generate standing privilege report
tigeridentity report standing-privileges \
  --output standing-access.json \
  --format json

# Example output shows permanent IAM role assignments
{
  "total_standing_grants": 234,
  "by_resource_type": {
    "aws_rds_database": 45,
    "aws_s3_bucket": 89,
    "kubernetes_namespace": 67,
    "github_repository": 33
  },
  "high_risk": [
    {
      "principal": "user_john_doe",
      "resource": "prod-db-master",
      "access_level": "admin",
      "last_used": "2026-01-15T08:23:00Z",
      "days_since_use": 21
    }
  ]
}

Key Metrics to Track

  • • Number of standing privileges by environment (dev, staging, prod)
  • • Unused access (last used > 90 days ago)
  • • Over-privileged users (admin access when read-only would suffice)
  • • Shared credentials and service accounts
2

Identify Standing Privileges to Remove

Prioritize which access to convert to JIT

Not all access needs to be JIT on day one. Start with high-risk, infrequently used privileges.

Prioritization Matrix

PriorityResource TypeCriteriaExample
HighProduction databases, secretsSensitive + infrequent useprod-postgres admin access
MediumCloud admin roles, SSHHigh privilege + moderate useAWS IAM admin, server SSH
LowDev environments, loggingLower risk + frequent usedev database read access

Phase 1 Targets (Week 1-2)

  • •Production database admin access (used 1-2x per week)
  • •Cloud infrastructure admin roles (break-glass scenarios)
  • •SSH access to production servers
  • •Secrets management systems (Vault, AWS Secrets Manager)
3

Design JIT Workflows

Create approval workflows and time limits

Define who can request access, who must approve, and how long sessions last.

Example: Production Database Access

# policies/prod-db-jit.yaml
apiVersion: v1
kind: Policy
metadata:
  name: prod-database-jit-access
spec:
  description: "JIT access to production databases with approval"

  resources:
    - type: database
      environment: production
      tags: { tier: critical }

  # Default: no standing access
  default_decision: deny

  rules:
    # Engineers can request time-limited access
    - name: engineer-jit-access
      effect: allow_with_approval

      principals:
        department: engineering
        role: [senior_engineer, staff_engineer]

      actions: [query, admin]

      # Approval workflow
      approval:
        required: true
        approvers:
          - type: manager  # Direct manager
          - type: role
            role: security_lead  # AND security lead

        auto_approve_if:
          - time_of_day: business_hours
          - emergency: false

        timeout: 1h  # Must be approved within 1 hour

      # Session limits
      session:
        max_duration: 2h
        can_extend: true
        max_extensions: 1
        require_justification: true

    # Break-glass for emergencies
    - name: emergency-access
      effect: allow

      principals:
        role: [oncall_engineer, security_lead]

      context:
        emergency: true  # Triggered via incident workflow

      session:
        max_duration: 4h
        require_justification: true

      # Alert security team
      notifications:
        - channel: slack
          webhook: https://hooks.slack.com/...
          message: "Emergency DB access granted to {principal}"

        - channel: pagerduty
          severity: high

Common Workflow Patterns

Auto-Approve During Business Hours

Low-risk access auto-approved M-F 9am-5pm

auto_approve_if: time_of_day == 'business_hours'

Manager + Security Dual Approval

High-risk access requires both approvals

approvers: [manager, security_lead]

Peer Review

Any team member with same clearance

approvers: { department: same, clearance: gte }

Resource Owner

Person responsible for the system

approvers: { type: resource_owner }
4

Create Policies

Implement your workflows in TigerIdentity

Apply your designed workflows to resources using TigerIdentity policies.

# Create the policy
tigeridentity policy create -f policies/prod-db-jit.yaml

# Verify it compiled correctly
tigeridentity policy validate prod-database-jit-access

# View what it affects
tigeridentity policy simulate prod-database-jit-access \
  --principal user_jane_doe \
  --resource prod-postgres-01 \
  --action admin

# Output
{
  "decision": "allow_with_approval",
  "matched_rule": "engineer-jit-access",
  "approval_required": true,
  "approvers": ["manager", "security_lead"],
  "session_duration": "2h"
}

Pro Tip: Start with Audit Mode

Deploy policies in audit-only mode first to see what would happen without enforcing. Review logs for unexpected denials before switching to enforce mode.

5

Test with Simulation

Validate policies before enforcement

Use TigerIdentity's policy simulator to test real scenarios without impacting production access.

Simulation Scenarios

# Test 1: Engineer during business hours
tigeridentity simulate \
  --policy prod-database-jit-access \
  --principal user_jane_doe \
  --resource prod-postgres-01 \
  --action query \
  --context '{"time_of_day": "business_hours", "emergency": false}'

# Expected: auto-approved, 2h session

# Test 2: Same engineer at 2am
tigeridentity simulate \
  --policy prod-database-jit-access \
  --principal user_jane_doe \
  --resource prod-postgres-01 \
  --action query \
  --context '{"time_of_day": "after_hours", "emergency": false}'

# Expected: requires dual approval

# Test 3: Emergency access
tigeridentity simulate \
  --policy prod-database-jit-access \
  --principal user_oncall \
  --resource prod-postgres-01 \
  --action admin \
  --context '{"emergency": true}'

# Expected: immediate access, 4h session, alerts sent

# Bulk test with CSV
tigeridentity simulate bulk \
  --policy prod-database-jit-access \
  --scenarios test-scenarios.csv \
  --output simulation-results.json

Review Simulation Results

Look for:

  • ✓Unexpected denials: Legitimate users blocked due to overly restrictive rules
  • ✓Unexpected approvals: Auto-approved when manual approval was intended
  • ✓Wrong approvers: Ensure manager lookup works correctly
  • ✓Session durations: Too long/short for the workflow
6

Deploy Gradually

Roll out to one team at a time

Don't enforce ZSP across your entire org on day one. Start with a pilot team and expand.

Recommended Rollout Phases

Week 1: Pilot Team (5-10 people)

Platform team with high security awareness. Enable for 1-2 production databases only.

Week 2: Engineering Department

Expand to all engineers. Add SSH access and cloud admin roles.

Week 3: Data & Analytics Teams

Cover data warehouse access, BI tools, ML platforms.

Week 4: Full Production

All teams, all production resources. Remove standing privileges.

# Deploy to pilot team first
tigeridentity policy deploy prod-database-jit-access \
  --scope '{"principals": {"department": "platform"}}' \
  --mode enforce

# Monitor for 1 week, then expand
tigeridentity policy deploy prod-database-jit-access \
  --scope '{"principals": {"department": "engineering"}}' \
  --mode enforce

# Finally, enforce org-wide
tigeridentity policy deploy prod-database-jit-access \
  --scope all \
  --mode enforce
7

Monitor & Alert

Track adoption and detect issues

Set up dashboards and alerts to monitor ZSP rollout health.

Key Metrics

0
Standing Privileges Remaining
94%
Access Requests Auto-Approved
8 min
Avg Time to Approval
12
Active Sessions (Current)

Alerts to Configure

# alerts/zsp-monitoring.yaml
alerts:
  - name: approval-timeout
    condition: request_pending > 1h
    severity: warning
    message: "Access request pending for {request_id} - approvers notified"

  - name: high-session-count
    condition: active_sessions_per_user > 5
    severity: info
    message: "User {principal} has {count} active sessions"

  - name: emergency-access-used
    condition: emergency_access_granted == true
    severity: high
    message: "Emergency access granted to {principal} for {resource}"
    notify: [security-team, oncall]

  - name: standing-privilege-detected
    condition: new_standing_access_created == true
    severity: critical
    message: "Standing privilege created outside of policy: {details}"
    notify: [security-team]
8

Iterate & Improve

Refine policies based on feedback

Collect feedback from users and adjust policies to balance security with productivity.

Common Adjustments

Session Duration Too Short

Symptom: Users constantly re-requesting access
Fix: Increase max_duration or enable session extensions

session: max_duration: 4h, can_extend: true

Approval Bottleneck

Symptom: Requests stuck waiting for unavailable approver
Fix: Add fallback approvers or auto-approve more scenarios

approvers: [manager, { type: department_lead, fallback: true }]

Too Many Alerts

Symptom: Security team overwhelmed by notifications
Fix: Adjust alert thresholds or aggregate notifications

notifications: rate_limit: 10/hour, aggregate: true

Monthly Review Checklist

  • Review access request approval times - target < 15 min
  • Check for any newly created standing privileges (should be 0)
  • Analyze denied requests for false positives
  • Survey users for friction points
  • Update policies based on new resources or team changes

Success Metrics

Track these metrics to measure the success of your ZSP implementation:

Security Improvements

  • • Standing privileges reduced by 95%+
  • • Average session duration < 3 hours
  • • 100% of prod access audited
  • • Emergency access used < 1x per month

User Experience

  • • 90%+ auto-approval rate
  • • Average approval time < 15 minutes
  • • < 5% request denials
  • • User satisfaction score > 4/5

Related Documentation

Policy Language
Learn policy syntax
JIT Sessions
Session management
Connectors
Integrate your systems

Ready to Implement ZSP?

Start your Zero Standing Privilege journey today

Start Free TrialTalk to an Expert