Service Account or Federated Workload?

You're facing a critical decision: how to manage a machine identity that needs cloud access. The application team wants it deployed by Friday. Your security lead insists on zero standing privilege. Meanwhile, your infrastructure engineer reminds you that half the estate still uses outdated credentials. You need a solution that balances risk with feasibility.

This choice isn't just theoretical. It impacts your system's vulnerability, audit readiness, and your peace of mind during incidents. Here's how to make the right decision.

The Decision at Hand

You're deciding between issuing a traditional service account with standing credentials or implementing workload identity federation for a machine needing programmatic access. A service account provides a credential stored in a vault, usable until rotated or revoked. Federation allows the workload to prove its identity to a trusted authority, receiving a short-lived token for a specific task.

The key difference: standing credentials can be exploited if stolen, while federation avoids having an exportable credential at all.

Key Factors Influencing Your Choice

Application Architecture. Can the workload request a token when needed, or does it require a username and password at startup? Modern container platforms and CI/CD pipelines often support OIDC. Legacy applications might not.

Trust Infrastructure. Federation needs a Policy Decision Point trusted by both parties. For instance, deploying a GitHub Actions workflow into AWS already has this trust. A fifteen-year-old batch process connecting to a vendor API may not.

Blast Radius. What damage can occur if the credential leaks? A CI/CD pipeline with production deployment permissions poses more risk than a read-only monitoring script. Palo Alto Networks found 61% of privileged access requests still use standing credentials. Prioritize high-value targets for change.

Rotation Capability. If federation isn't possible, can you at least reduce credential lifespan? Some vault platforms issue dynamic database credentials for session durations. It's not zero standing privilege, but it's better than a static password.

Path A: Workload Identity Federation

Choose this when:

• The workload runs on a platform issuing signed identity tokens (Kubernetes, GitHub Actions, Google Cloud Build, Azure DevOps, GitLab CI).
• The target system accepts OIDC or another federation standard.
• The access pattern is request-driven.
• The credential would otherwise carry critical privileges.

Implementation:

Configure the workload platform as an identity provider in the target system's trust policy. For GitHub Actions deploying to AWS, register GitHub's OIDC endpoint in AWS IAM and create a trust relationship tied to your repository. The workflow requests a token from GitHub, presents it to AWS, and receives temporary credentials scoped to the IAM role. These credentials expire automatically, typically within an hour.

Requirement Drivers:

Under PCI-DSS 4.0, requirement 8.3.2 mandates multi-factor authentication for all access into the cardholder data environment, including non-console access. Federation with platform-issued identity meets this requirement more effectively than retrofitting MFA onto a service account.

Path B: Vault-Issued Dynamic Credentials

Choose this when:

• The application can't federate but can fetch a credential at runtime.
• You control the target system enough to allow programmatic account creation.
• The access is session-based.
• You're dealing with databases, SSH targets, or internal APIs.

Implementation:

Set up your vault (HashiCorp Vault, CyberArk, or equivalent) to generate credentials on demand. When the application requests access, the vault creates a temporary account in the target system with the necessary permissions, provides the credentials, and schedules the account for deletion when the lease expires.

Requirement Drivers:

This approach moves you closer to zero standing privilege without needing federation support from legacy systems. It also offers centralized revocation, crucial for incident response. To cut off access during an investigation, revoke the vault role instead of hunting through systems for accounts to disable.

Path C: Managed Service Account with Aggressive Rotation

Choose this when:

• The application requires a static credential.
• You don't control the target system (vendor SaaS, partner API, legacy appliance).
• Federation and dynamic secrets aren't feasible.
• You've documented and accepted the risk.

Implementation:

Store the credential in a vault with the shortest rotation schedule the application can handle. Thirty days is common, but some teams reduce this to seven. Enforce strict access controls on credential retrieval and log every access with correlation to the requesting workload.

Treat this as technical debt. Tag it in your asset inventory, assign an owner, and set a review date to reassess federation feasibility.

Requirement Drivers:

Even with standing credentials, you can demonstrate control. NIST SP 800-53 control IA-5(1) requires automated support for password management, including rotation. Vault-managed rotation with audit logging meets this requirement more defensibly than a password stored in a wiki.

Summary Matrix

The Salesloft incident in August 2025 showed the risks of OAuth refresh tokens as standing credentials. Attackers used stolen tokens tied to the Drift integration to access Salesforce data in over 700 organizations. The tokens were valid, and no MFA challenge was triggered. Google Threat Intelligence Group traced the initial access back to a GitHub account compromise months earlier.

Your goal isn't to eliminate every service account immediately. Start with an inventory naming an owner for each machine credential, then prioritize by blast radius. Move CI/CD pipelines and cloud admin workflows to federation first. Shorten rotation windows on everything else. Track the percentage of machine access granted on demand versus held permanently, and focus on improving that ratio over time.