Why Zero Standing Privilege Is the Future of IAM
Static RBAC was designed for a world that no longer exists. As enterprises adopt thousands of SaaS tools, multi-cloud infrastructure, and AI agents, standing privileges have become the primary attack vector in modern breaches.
When RBAC (role-based access control) was designed in the 1990s, the enterprise security model was simple: employees logged into a handful of applications from corporate networks, and their access remained relatively stable. Roles like "Finance Manager" or "Sales Director" made sense because job functions were predictable and systems were few.
Today, that world is gone. The average enterprise uses over 1,000 SaaS applications. Developers deploy to multi-cloud infrastructure with dozens of CI/CD pipelines. Service accounts outnumber humans 10:1. AI agents are accessing production databases and customer data. And employees work from anywhere, using any device.
In this environment, standing privileges — persistent, always-on access granted based on job titles — have become the number one cause of lateral movement in security breaches. Zero Standing Privilege (ZSP) is the solution.
The Standing Privilege Problem by the Numbers
What Is Zero Standing Privilege?
Zero Standing Privilege is a security model that eliminates persistent access to resources. Instead of granting users and services always-on permissions based on their role, ZSP provides access just-in-time, scoped to specific resources, and automatically expires after use.
In a ZSP model, access is granted dynamically based on real-time context — who is requesting access, what resource they need, when they're requesting it, why they need it, and what risk signals are present. When the task is complete, access is automatically revoked.
Static RBAC
- •Permanent access based on job title
- •Access granted broadly across resources
- •Credentials never expire automatically
- •No consideration of context or risk
- •Access reviewed quarterly or annually
- •Cleanup requires manual intervention
Zero Standing Privilege
- •Just-in-time access based on need
- •Scoped to specific resources only
- •Automatic expiration after task completion
- •Dynamic evaluation of context and risk
- •Continuous re-evaluation during sessions
- •Zero cleanup needed — access self-revokes
How TigerIdentity Implements ZSP
TigerIdentity's Continuous Identity Platform is built from the ground up to deliver Zero Standing Privilege across humans, service accounts, and AI agents. Here's how it works:
Dynamic Policy Engine
Policies evaluate real-time context — not just role membership. Access decisions consider time of day, location, device posture, risk score, business signals (like active incidents), data sensitivity, and behavioral patterns. The policy engine evaluates every request in under 50ms.
Just-in-Time Access
Instead of granting permanent credentials, TigerIdentity issues temporary access tokens with automatic expiration. A developer requesting production database access gets a credential valid for 2 hours — not a password that works forever. Service accounts and AI agents follow the same model.
Continuous Evaluation
Access isn't just evaluated at login — it's re-evaluated continuously throughout the session. If context changes (user leaves the office, risk score spikes, incident is resolved), TigerIdentity can revoke access immediately, mid-session, without waiting for token expiration.
CAEP Session Control
TigerIdentity implements the Continuous Access Evaluation Protocol (CAEP) and OpenID Shared Signals Framework. When a security event occurs — device compromise, credential leak, policy violation — all active sessions are revoked instantly across every connected system.
ZSP in Practice: A Real Policy
Here's what a Zero Standing Privilege policy looks like in TigerIdentity. This policy governs production database access — only granting it to on-call engineers during active incidents, with a maximum duration of 2 hours:
policy "production-database-access":
description: "Zero standing privilege for production database"
principals:
type: human
attributes:
role: [engineer, sre]
resources:
type: database
environment: production
sensitivity: high
default_decision: deny
rules:
# Grant access ONLY during active incidents
- name: incident-response-access
effect: allow
conditions:
# User must be on-call right now
- pagerduty.is_on_call(principal.email) == true
# There must be an active P0/P1 incident
- incident.is_active() == true
- incident.severity in ["P0", "P1"]
# User must be assigned to the incident
- incident.assigned_to contains principal.email
# Access limited to business hours + 2hr window
- time.hour >= 6 && time.hour <= 22
# Risk score must be acceptable
- principal.risk_score < 70
# Device must be corporate-managed
- device.is_managed == true
- device.os_patch_level <= 7 # Days behind
# Automatic expiration
max_duration: 2h
# Auto-revoke when conditions no longer met
continuous_evaluation: true
# Require MFA step-up
require_authentication:
methods: [webauthn, totp]
max_age: 5m
# Explicit deny for all other scenarios
- name: default-deny
effect: deny
priority: 100
# Audit requirements
audit:
log_level: detailed
require_justification: true
alert_on_access: true
notify:
- [email protected]
- incident-commanderWhat This Policy Does
- No standing access: Engineers have zero production database access by default — even senior SREs.
- Context-driven: Access granted only during active P0/P1 incidents when the user is on-call and assigned to that incident.
- Time-bound: 2-hour maximum duration with automatic expiration.
- Continuous evaluation: If incident resolves or user goes off-call, access revokes immediately.
- Security controls: Requires MFA, corporate device, acceptable risk score, and patch compliance.
- Full auditability: Every access attempt logged with justification and real-time alerts to security team.
The Business Case for ZSP
Zero Standing Privilege isn't just a security improvement — it's a business enabler. Here are the three key benefits enterprises are seeing in production:
Reduce Blast Radius
When an account is compromised — whether through phishing, credential stuffing, or insider threat — it has zero persistent access. Attackers can't pivot laterally because there are no standing privileges to abuse.
Real-world example: A customer's developer laptop was stolen with saved credentials. In their old RBAC model, those credentials would have granted access to 15+ production systems.
With ZSP, the stolen credentials had zero standing access. The attacker couldn't access anything without passing real-time policy checks (MFA, device verification, business context).
Simplify Compliance
Access is auditable, time-limited, and justified by design. When auditors ask "who had production database access in Q4?", the answer is precise: every access grant with full context, duration, and business justification.
Compliance wins:
- • SOC 2 access reviews automated (no quarterly manual audits)
- • GDPR data access requests answered in minutes, not days
- • PCI DSS privileged access logging built-in by default
- • Zero unused permissions (automatic cleanup)
Enable Agility
In traditional models, developers wait days for access requests to be approved, provisioned, and configured. With ZSP, they get access when they need it — instantly, automatically, and securely.
Developer experience: An engineer joins the on-call rotation. The moment they're paged for a production incident, they automatically receive temporary access to debugging tools, logs, and databases — no Slack messages, no ticket queues, no delays.
When the incident resolves, access auto-revokes. Security and velocity working together, not against each other.
Ready to Eliminate Standing Privileges?
Join enterprises already running Zero Standing Privilege in production with TigerIdentity. Deploy in days, not months — with zero changes to your applications.
30-day trial. No credit card required. Full platform access.