Zero Standing Privilege for Service Accounts

For a human, Zero Standing Privilege is legible: request → approve → time-boxed grant → revoke. For a service account running a batch job every 60 seconds, that flow makes no sense. Nobody is going to approve 1,440 access requests per day.

But the same principle applies. A service account should hold credentials only for the duration of its actual work, not permanently. The mechanism has to change; the goal does not.

The confusion most teams run into is conflating ZSP with JIT access request workflows. JIT for humans works because humans are slow — they request, wait for approval, do their work, and return the access. Service accounts are fast, programmatic, and sometimes issuing hundreds of calls per minute. JIT workflow tooling designed for humans breaks on this population. What service accounts need is not a workflow — it is a credential issuance architecture that makes standing access unnecessary by design.

What ZSP means for workloads

The credential lifecycle in a ZSP architecture

The key architectural shift is moving credential lifecycle management from a provisioning-time event to a runtime event. In the legacy model, a DevOps engineer creates a service account, generates a key, stores it in a secrets manager, and the workload reads it at startup. The credential is valid until someone remembers to rotate it — which, in practice, is never.

In the ZSP model, there is no key to provision. The workload presents a verifiable identity claim — a Kubernetes service account token, a SPIFFE SVID, or a cloud IMDS attestation — to a credential broker. The broker validates the claim, evaluates policy, and issues a short-lived credential scoped to the declared task. When the task completes, the credential is not revoked — it expires naturally, because it was short-lived by design.

The operational consequence is significant: there is nothing to rotate. The concept of rotation is a compensation mechanism for long-lived credentials. When credentials expire in six minutes, rotation becomes irrelevant. The security surface reduces dramatically, and the compliance narrative simplifies to "show me the TTL distribution" rather than "show me the rotation audit log."

The runtime shape

# Every 60s: batch job wakes, requests scoped credentials, exits

workload:
  identity: svc-billing-export.production
  attestation:
    method: workload_identity_federation
    issuer: k8s-oidc

  request:
    intent: export_daily_billing
    resources:
      - action: bigquery.jobs.create
        project: billing-warehouse
      - action: storage.objects.create
        bucket: gs://exports/billing/2026/*

  policy:
    max_ttl: 8m
    require_healthy_signal: true
    require_owner_active: true

  response:
    credentials: short_lived
    ttl: 6m
    audit_id: tid-2026-...
    tidr_hook: true

The `tidr_hook: true` field is worth dwelling on. When it is set, TIDR monitors the session in real time. If the billing export job starts behaving in a way that does not match its baseline — accessing resources it has never touched, calling APIs at unusual rates, making cross-region calls — the TIDR engine can signal the credential broker to deny the next renewal. The ZSP architecture and the behavioural detection layer are not separate systems; they are deliberately coupled.

What has to be true for this to work

• Workload attestation. The identity requesting credentials must be provable. Kubernetes workload identity federation, SPIFFE SVIDs, or cloud IMDS-based attestation.
• Sub-50 ms decisions. If credential issuance adds 400 ms, every job slows down. Policy evaluation on the hot path must be indistinguishable from environment lookup.
• Consumer libraries that refresh. Apps should use SDKs that call the broker every N minutes, not read a token at boot and hold it.
• TIDR feedback. If a workload's behaviour drifts, the next credential request can be denied or step-up-required. ZSP without behavioural feedback is only halfway there.
• A consumer manifest for each workload. Policy evaluation requires knowing what resources the workload legitimately needs. This is defined in a manifest, not derived ad-hoc from what the workload requests.
• Owner accountability. Every service account needs a human owner who is responsible when policy alerts fire. Orphaned service accounts in a ZSP architecture are a contradiction — they need to be retired, not merely governed.

ZSP by workload type

Not all service accounts have the same shape. The ZSP implementation pattern varies by workload type, and conflating them is a common mistake.

Rolling out ZSP without breaking production

The most common objection to ZSP for workloads is operational risk: "if the credential broker goes down, everything stops." That is true if the broker is a single point of failure and if workloads have no fallback. Neither should be true in a well-designed deployment.

1. Start with new workloads only. Apply ZSP by default to every new service account provisioned. The existing fleet migrates over 6–12 months on a prioritised schedule.
2. Run the broker in a highly available configuration. Three replicas across availability zones, with a warm standby in a second region. Target 99.99% uptime — higher than most production services.
3. Cache the last-issued credential for the job TTL. If the broker is briefly unreachable, the workload uses the cached credential until it expires, then retries. Do not make unavailability an incident.
4. Instrument everything. Track credential issuance latency in your SLO dashboard alongside your application metrics. Make the broker a first-class observable service, not infrastructure you forget about.

What we see when teams get this right

• Median NHI credential TTL drops from months to minutes.
• Static keys in secrets managers fall by 70–90% within one quarter.
• Incident response times collapse — a compromised credential is often already expired by the time detection fires.
• Compliance narratives simplify: "No workload holds standing privilege" is a much easier story than "These 400 workloads have justified exceptions."
• Offboarding cleans up automatically. When a human owner leaves, orphaned service accounts surface immediately rather than persisting for years with expired attribution.
• Security team capacity shifts. Instead of chasing rotation exceptions, the team focuses on policy refinement and genuine anomalies surfaced by TIDR.

The teams that have fully rolled out ZSP for service accounts consistently report the same thing: the first few weeks feel like adding friction, and then something flips. Once the operational muscle is built — once credential issuance is as automatic as DNS resolution — the standing-privilege model starts to look obviously broken in retrospect. The question is no longer "why would we rotate credentials?" but "why would we ever issue a credential that does not expire?"