Guides

Machine Identity Security: Service Accounts, Keys and Workloads

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Machine identity covers workloads that authenticate without a human at the keyboard: service accounts, API keys, CI/CD tokens, certificates, cloud instance roles and workload identities. Secure them with unique identities, vault or managed credentials, short lifetime, least privilege, rotation and audit — not shared passwords in chat. Defence and builder hygiene only; no credential-theft recipes.

Workload → its own ID → short-lived or vaulted secret → least privilege → audit
Shared forever-password in git = breach waiting to publish

What do I need before this guide?

• Human IAM habits: Cloud IAM least privilege.
• AD context: Active Directory hardening and monitoring.
• Optional: Software supply chain / secrets.
• Lab: a throwaway app or cloud sandbox you control.

What is machine identity?

Common machine identities (defender vocabulary)

1. OS / directory service accounts — Windows services, Linux daemons bound to domain or local users.
2. Cloud instance / workload identities — roles attached to VMs, functions, Kubernetes service accounts.
3. CI/CD and automation tokens — pipeline secrets that deploy or call APIs.
4. API keys and client credentials — OAuth client secrets, vendor integrations.
5. Certificates and keys — mTLS client certs, code-signing (protect and inventory separately).
6. RPA / bot accounts — often over-privileged “human impersonators” — treat as machines with owners.

Educational warning: do not harvest tokens from other tenants, crack service passwords, or exfiltrate CI secrets. Practise rotation and vault wiring on systems you own.

Real incident: CI secrets exposure pattern (CircleCI 2023, public lessons)

Public reporting around CircleCI’s January 2023 security incident described customer urgency to rotate secrets that might have been exposed via the CI environment. Separately, years of breach reports show the same root theme: long-lived pipeline credentials and secrets copied into many tools create a wide blast radius when any one system is abused.

Takeaways (vertical):

1. What happened — CI-adjacent trust forced emergency rotation across many customer secrets.
2. What went wrong (theme) — valuable machine credentials concentrated and sometimes overly long-lived.
3. Care-take — inventory CI secrets; rotate on vendor advisory without waiting for “proof of use”.
4. Care-take — prefer OIDC / short-lived cloud roles from pipelines over static access keys when possible.
5. Care-take — revoke first, investigate second when a vault or CI path may be tainted.
6. Bonus parallel — Codecov-style supply-chain reports also stressed reviewing CI secrets after trust breaks.

Human vs machine identity

1. Humans: MFA, phishing-resistant factors, joiner/leaver tickets.
2. Machines: no interactive MFA prompt — compensate with platform attestation, network allow-lists, short TTL and vault issuance.
3. Do not share a human’s password with a batch job “just for tonight”.
4. Break-glass human admins stay separate from deploy bots.
5. Fictional Mauli Dairy, Pune: the invoice API uses a cloud role on the app host; developers never paste the old static key into Telegram.

Password-less machines still need owners

1. A cloud role with no human password can still wipe a database — ownership and least privilege remain mandatory.
2. ChatOps bots that run privileged commands need the same change control as humans typing those commands.
3. Record the business purpose: “deploy invoices API” beats “misc automation”.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Find secrets in git history, ticket attachments, container env dumps (high-level).
• Abuse over-privileged CI roles to reach production data.
• Keep persistence via forgotten service accounts that nobody rotates.

Blue Team — defend, detect, respond

• Secret scanning in repos and pipelines; block merges on high-entropy leaks.
• Alert on unused identities suddenly authenticating after months quiet.
• Conditional access / IP allow-lists for automation where supported.
• Rapid revoke playbooks for CI and vault incidents.
• Quarterly attestation: owner confirms each machine identity still needed.

How do I secure service accounts step by step?

Step 1 — Inventory spreadsheet (start ugly)

1. Columns: name, system, owner, privilege summary, secret location, last rotated, expires.
2. Mark anything with Domain Admin / cloud *:* / production DB admin as P0.
3. Delete orphan identities after owner confirmation.

Step 2 — Replace the worst patterns

1. Static AWS keys on laptops → IAM roles on compute or SSO short sessions.
2. AD service password in a share → gMSA or vault-issued secret with rotation.
3. One Jenkins user that can deploy everywhere → split per environment.
4. Certificates: track expiry; alert 30 days prior.

Step 3 — Operate

1. Every pipeline secret has an expiry or rotation job.
2. Production deploy credentials cannot be read by feature-branch pipelines.
3. Application configs pull from vault at runtime; no secrets in images.
4. Audit logs reviewed for machine identities like you review human admins.

Step 4 — Lab drill

1. Create a fake API key for a toy app on your laptop.
2. Put it in vault (or password manager as a training stand-in); remove from .env committed copies.
3. Rotate it once; confirm the old value fails; write the five-line note.

Short-lived credentials beat “forever keys”

1. Cloud instance roles and workload identity federation mint temporary credentials — prefer them for compute.
2. OIDC into cloud from GitHub Actions / GitLab / similar removes many static deploy keys when configured carefully.
3. Certificate-based client auth needs inventory and renewal automation — expiry is an availability and security event.
4. If a vendor only offers a long-lived API key, isolate it: network allow-list, minimal scopes, 90-day rotation, dedicated owner.
5. Document the revoke button location before an incident — panic searching wastes hours.

Lab warning

Practise vault wiring and rotation on your sandbox. Do not revoke credentials on an employer or client tenant without change tickets and approval. Do not scan the public internet for exposed keys to “help notify” — use official disclosure channels if you find something accidentally in your own telemetry.

Care-take — organisation habits

1. Secrets in tickets = regenerate immediately.
2. Third-party integrations get unique credentials per vendor.
3. Offboarding removes human and the bots they owned.
4. Signing keys offline or in HSM per policy — not on the intern laptop.
5. Tabletop: “CI advisory says rotate within 24h — who owns the list?”
6. Prefer federation over copying passwords into yet another SaaS.

How do I fix common machine-identity mistakes?

Ghabru naka 😅 — these are the usual ones: