The Problem with Standing Privileges
Standing privileges — persistent access rights that remain active whether or not they are being used — represent one of the largest attack surfaces in enterprise environments. A database administrator who has 24/7 root access to production databases creates a permanent target for credential theft, even though they may only need that access for a few hours each week during maintenance windows. An AWS IAM role with AdministratorAccess attached to a developer’s account sits idle 95% of the time, but if those credentials are compromised, the attacker inherits full administrative control instantly.
The Zero Trust principle of least privilege requires not just limiting what access is granted, but also limiting when and for how long that access persists. Short-lived credentials and Just-in-Time (JIT) access are the mechanisms that enforce temporal least privilege — ensuring that elevated access exists only for the duration it is needed and is automatically revoked afterward.
Free to use, share it in your presentations, blogs, or learning materials.
The above illustration contrasts the two approaches to credential management. The traditional model grants standing credentials that persist indefinitely, creating a large and growing attack surface over time. The Zero Trust model issues short-lived credentials with a TTL of 4 to 24 hours through a controlled lifecycle: request, approval, issuance, active use, automatic expiration, and audit logging.
Short-Lived Credentials: Architecture and Implementation
Short-lived credentials replace static, long-lived secrets (API keys, passwords, service account keys) with dynamically generated credentials that expire after a defined period. The credential’s lifetime is typically measured in minutes or hours rather than months or years.
HashiCorp Vault Dynamic Secrets
Vault’s dynamic secrets engine generates credentials on demand with built-in TTL (Time to Live) and automatic revocation. When an application requests database credentials, Vault creates a new database user with the specified permissions and a TTL of, say, one hour. When the TTL expires, Vault automatically drops the database user. No credential rotation is needed because the credential ceases to exist.
A practical Vault configuration for PostgreSQL dynamic secrets involves configuring the database secrets engine with a connection URL to the target PostgreSQL instance and a creation statement that generates users with specific roles. The role definition sets a default TTL of one hour and a maximum TTL of four hours. Applications request credentials via the Vault API, receive a username and password, and use them for the duration of their operation. If the application crashes or the TTL expires, the credentials are automatically revoked.
Free to use, share it in your presentations, blogs, or learning materials.
This diagram highlights the dynamic secrets lifecycle managed by HashiCorp Vault. An application requests credentials through the Vault API, Vault generates a unique set of temporary credentials with a defined time-to-live, and upon expiration the credentials are automatically dropped from the target system, eliminating the risk of stale or forgotten secrets persisting in the environment.
Cloud-Native Short-Lived Credentials
- AWS STS (Security Token Service): Issues temporary security credentials with configurable duration (15 minutes to 12 hours). AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity generate short-lived access keys, secret keys, and session tokens. Best practice is to never create IAM user access keys — instead, use IAM roles with STS-issued temporary credentials exclusively.
- GCP Workload Identity Federation: Allows external workloads (CI/CD pipelines, on-premises services) to exchange their native identity tokens for short-lived GCP access tokens without storing service account keys. The access tokens have a one-hour lifetime by default.
- Azure Managed Identities: Assign identities to Azure resources (VMs, App Services, AKS pods) that automatically obtain and rotate short-lived tokens from the Azure Instance Metadata Service. No secrets are stored in the application or its configuration.
Just-in-Time Access: Elevating Privileges on Demand
JIT access takes temporal least privilege further by requiring explicit approval or automated policy evaluation before elevated access is granted. Instead of a DBA having persistent production access, they request access through a JIT workflow, receive time-bounded credentials after approval, and lose access when the window expires.
JIT Workflow Components
- Access request: The user submits a request specifying the resource, permission level, duration, and justification (ticket number, incident ID, change request reference).
- Policy evaluation: An automated policy engine evaluates whether the request aligns with the user’s role, the resource’s sensitivity, and organizational policies. Low-risk requests (developer accessing a staging database) may be auto-approved. High-risk requests (admin access to production infrastructure) require manager or security team approval.
- Credential issuance: Upon approval, the system provisions time-bounded credentials — an IAM role assumption, a Vault-issued secret, a Kubernetes RBAC binding with a TTL, or an SSH certificate with a short validity period.
- Session monitoring: All actions performed during the elevated session are logged and can be recorded (session recording for SSH, query logging for databases, CloudTrail for AWS API calls).
- Automatic revocation: When the time window expires, credentials are revoked automatically. No manual intervention, no forgotten elevated permissions lingering for months.
As shown above, the JIT access workflow enforces a structured sequence: the user requests access with a justification, the policy engine evaluates the request against organizational rules, an approver grants time-bounded permission, credentials are issued with a strict TTL, and once the window expires the credentials are automatically revoked, leaving zero standing privileges behind.
Real-World JIT Implementations
Several tools and platforms provide JIT access capabilities that integrate into existing infrastructure.
Teleport: Provides JIT access for SSH, Kubernetes, databases, and web applications. Users request elevated access through the Teleport UI or CLI, approvers receive notifications via Slack or PagerDuty, and approved sessions are time-bounded and recorded. Teleport issues short-lived X.509 certificates for each session, eliminating the need for SSH keys or database passwords.
CyberArk and BeyondTrust: Enterprise PAM solutions that provide JIT privileged access with session recording, credential vaulting, and approval workflows. These integrate with ITSM platforms (ServiceNow, Jira) to tie access requests to change management processes.
AWS IAM Access Analyzer and Permission Boundaries: While not a full JIT solution, AWS provides building blocks. Permission boundaries restrict the maximum permissions a role can have, and you can build JIT workflows using Step Functions that temporarily attach policies, trigger a CloudWatch Events timer, and automatically detach the policy after the window expires.
Azure PIM (Privileged Identity Management): Natively provides JIT access for Azure AD roles and Azure resource roles. Users activate roles for a configurable duration (up to 24 hours), with optional approval workflows and MFA enforcement at activation time. All activations are logged in the Azure AD audit log.
Implementing JIT for Kubernetes
Kubernetes environments particularly benefit from JIT access. Persistent cluster-admin bindings are a common finding in security assessments and represent excessive standing privilege. A JIT model for Kubernetes involves creating a self-service portal or Slack bot where developers request elevated access to a specific namespace for a defined duration. The system creates a temporary RoleBinding or ClusterRoleBinding with a TTL, often implemented via a Kubernetes CronJob or a custom controller that deletes expired bindings.
A more elegant approach uses Teleport or a custom admission webhook. When a developer runs kubectl with their OIDC token, the webhook evaluates whether they have an active JIT session. If yes, the request proceeds with the elevated permissions. If not, it returns a 403 with instructions to request access. The JIT session is tracked as a custom resource in Kubernetes, and a controller watches for expired sessions and cleans up the associated RBAC bindings.
Free to use, share it in your presentations, blogs, or learning materials.
The above illustration depicts how JIT access is implemented in a Kubernetes environment. A developer requests namespace-scoped access, the JIT system creates a temporary RoleBinding with a defined TTL, and a custom controller continuously watches for expired bindings and removes them automatically, ensuring no persistent cluster-admin privileges remain after the maintenance window closes.
Operational Best Practices
Deploying short-lived credentials and JIT access requires operational discipline to avoid creating new pain points.
- Credential TTL calibration: Set TTLs based on actual usage patterns. If database maintenance typically takes 45 minutes, set a one-hour TTL with the option to extend. Overly short TTLs that force frequent re-authentication create friction that drives workarounds.
- Automated renewal for long-running jobs: Batch processes, data pipelines, and CI/CD runs may exceed default credential TTLs. Implement credential renewal logic in your applications — Vault Agent, AWS SDK automatic credential refresh, and sidecar containers that handle token renewal are standard patterns.
- Break-glass procedures: Define and test emergency access procedures for scenarios where the JIT system itself is unavailable. Pre-sealed emergency credentials stored in a physical safe with tamper-evident seals, requiring dual-custody access and generating immediate alerts, provide a fallback without undermining the JIT model.
- Audit and analytics: Log every credential issuance, JIT session activation, and revocation event. Analyze patterns to identify users who consistently request maximum-duration access (potential for TTL adjustment), resources that are accessed via JIT more than 10 times per day (candidates for standing access with ABAC controls), and JIT requests that are approved but never used (potential policy refinement).
The transition from standing privileges to short-lived, JIT credentials is not instantaneous. Begin with your highest-risk access paths — production infrastructure, cloud admin roles, and database root access. Measure the reduction in standing privilege exposure (number of persistent admin accounts multiplied by time) as a key security metric. Over time, the goal is zero standing privileges: every elevated access is requested, justified, time-bounded, monitored, and automatically revoked.