The Service Account Crisis: Triage Your 82:1 Machine Identity Ratio

Your MFA project covers humans. It doesn’t cover the other 82 identities per employee. Silverfort’s 2025 global study found enterprises average 82 machine identities per human employee, which means a 5,000-person organization is quietly operating roughly 410,000 active service accounts, API keys, and workload identities. Most of them have static credentials, over-broad permissions, and no owner.

This is Phase 1, Chapter 2 of our 90-Day Zero Trust Playbook. Human MFA matters. But CrowdStrike reports 79% of attacks are now malware-free, relying on valid credentials for lateral movement. If you solve human identity and ignore machine identity, you’ve closed the front door while leaving 82 side doors open per employee. The axios npm compromise was exactly this failure mode, static publishing credentials, no rotation, no MFA.

Key Takeaways

• Enterprises run 82 machine identities per human employee, pushing a 5,000-person org past 410,000 active service accounts (Silverfort, 2025)
• 79% of attacks are malware-free, using valid credentials; 65% of initial access is identity-driven (CrowdStrike/Deepstrike)
• Under 40% of organizations use MFA for privileged accounts; 20% never change default vendor passwords (BeyondTrust)
• Orphaned accounts plague 79% of healthcare orgs, 64% of financial services, 44% of manufacturing (Orchid Security)
• 50%+ of orgs still manage service accounts manually, 18% on paper and 36% in spreadsheets (ManageEngine)

Why Is the 82:1 Ratio So Alarming?

Silverfort’s 2025 study pegs the conservative enterprise ratio at 82 non-human identities per employee, with cloud-native environments reaching 40,000:1 for specific workloads. Saptang Labs notes that in Active Directory, roughly one-third of all user objects are service accounts, most predating the current security team.

The blast radius compounds from there. Deepstrike’s analysis of 2025-2026 breach data reports 99% of cloud identities are over-permissioned and 65% of initial access is identity-driven. Compromised credentials cost an average of $4.50M per breach. When an attacker lands on a static service-account password, they inherit whatever permissions that account has accumulated over a decade, which is usually “more than anyone remembers granting.”

How Broken Is Current Service Account Management?

The industry-state data from BeyondTrust and ManageEngine reads like a confession: under 40% of organizations use MFA for privileged accounts, 20% never change default vendor passwords, 33% allow password sharing, and more than half manage the problem manually, with 18% keeping records on paper.

Orphaned accounts are the quiet majority. Orchid Security’s orphan account report found 79% of healthcare organizations, 64% of financial services, and 44% of manufacturing carry 1,000+ orphaned accounts. Tenfold Security reports 42% of organizations don’t know how many orphans they have. You can’t rotate what you can’t see.

What’s the Triage Framework?

You won’t fix 410,000 machine identities in 90 days. You don’t need to. You need a triage framework that prioritizes the accounts most likely to be abused. The axis that matters is criticality (what can this account access?) crossed with credential type (static or dynamic?).

Four quadrants, four actions:

• Critical + Static secrets (Immediate). Domain admin service accounts, CI/CD publishing tokens, database superusers with fixed passwords. These are the axios-style blast radius. Vault them, rotate now, enforce break-glass workflows.
• Critical + IAM roles (Audit). Cloud workload identities with admin-equivalent permissions. Already dynamic, but usually over-permissioned. Audit against actual API calls in CloudTrail or equivalent, downscope.
• Non-critical + Static (Phase 1). Monitoring agents, backup scripts, integration users. Scheduled rotation plus migration to a secrets manager over 60-90 days.
• Orphaned (Special case). Disable with 30-day grace period. If nothing breaks, delete. If something breaks, you’ve just discovered an unowned production dependency, which is itself a finding.

This prioritization is the same logic as the Application Criticality Scorecard, applied to identity. Scope creep kills ZTA programs. Triage prevents it.

What’s the Migration Path Off Static Secrets?

The end state is OIDC federation for CI/CD and dynamic, short-lived credentials for everything else. The migration runs in three stages.

Stage 1: Inventory and vault. Pull every static secret into HashiCorp Vault, AWS Secrets Manager, or equivalent. Vault Community is free; Vault Enterprise starts around $100K/year for small deployments. The inventory alone surfaces 20-40% of accounts that can be deleted outright.

Stage 2: Dynamic secrets. For databases, cloud APIs, and internal services, generate credentials on-demand with 1-24 hour TTLs. This kills the “10-year-old static password” problem at the root.

Stage 3: OIDC federation for CI/CD. GitHub Actions, GitLab, and Buildkite all support OIDC tokens against major clouds, eliminating stored deploy secrets entirely. The typical migration runs 6-12 weeks in waves. This is the specific control that would have blunted the axios compromise and the September 2025 NPM 18-package attack that affected 2.6 billion weekly downloads.

Why Is This Phase 1 and Not Later?

Because 79% of attacks are now malware-free and service accounts are the usual pivot. Deferring machine identity to Phase 3 means shipping Phase 2 micro-segmentation policies that assume a trust model which doesn’t exist. Every lateral-movement incident in the Verizon 2025 DBIR starts with a credential that shouldn’t have worked, and service-account credentials are the ones least likely to have MFA, rotation, or monitoring.

Pragmatically: you won’t finish machine identity in 90 days. You will finish the triage, inventory the criticals, vault the static secrets for Tier 1 apps, and stand up the migration program. That’s enough to close the worst of the exposure while Phase 2 and Phase 3 unfold.

FAQ

What counts as a service account in this context?

Any authenticated identity used by code, not a person: Active Directory service users, API keys, OAuth client credentials, cloud IAM roles, Kubernetes service accounts, database users, SSH keys, certificates, CI/CD tokens. Silverfort’s 82:1 ratio aggregates all of these into “machine identities,” which is the right mental model for Zero Trust scoping.

How do I find orphaned service accounts?

Cross-reference every service account against: last authentication event (older than 90 days is suspicious), associated owner in your CMDB or IdP, and active production workload. Tenfold Security’s guidance suggests quarterly reviews, but for Phase 1 triage, run a one-time report now. Expect 10-30% of accounts to have no identifiable owner.

Should I rotate all static secrets immediately?

No. Rotate Tier 1 criticals (domain admin, CI/CD publishing, database superuser) immediately. Schedule Tier 2 and Tier 3 on 30-90 day cycles tied to vault migration. Mass rotation without coordination breaks production workloads and destroys trust in the program, which is what stalls it. Triage first, then rotate.

Is MFA feasible for service accounts?

Sometimes, and you should push for it on privileged ones. Under 40% of organizations currently use MFA for privileged accounts, which is a Phase 1 gap. For non-interactive workloads, the equivalent control is short-lived credentials via OIDC or mTLS, which achieves the same “verify each access” property without a human-style second factor.

How does this connect to the axios npm incident?

Directly. The axios compromise used stolen publishing credentials that had no MFA, no rotation, and broad permissions, exactly the Critical + Static quadrant of the triage matrix. The same pattern repeated in Ultralytics PyPI (Dec 2024), tj-actions (early 2025), the NPM 18-package attack (Sep 2025), and Trivy (Mar 2026). Service account triage is the specific control that addresses this attack class.

What about AI agent identities?

Treat them as service accounts, with stricter scoping. AI agents that call APIs on behalf of users create new machine identities with human-scale permissions, which is the worst of both worlds. The Nx “s1ngularity” attack in August 2025 specifically exploited local AI tools (Claude Code, Gemini CLI, Amazon Q) to extract secrets, making this category a 2026 priority for most security programs.

Can we do this with free tooling?

Partially. HashiCorp Vault Community is free and covers secret storage plus dynamic secrets for most common backends. Cloud-native IAM (AWS IAM, Azure AD, GCP IAM) is included with the cloud bill. The commercial step-up is Vault Enterprise or SaaS equivalents for HA, namespaces, and compliance reporting, typically $100K+/year for enterprise deployments.

Where This Fits in the 90-Day Playbook

Phase 1 is identity for humans and identity for machines, in parallel. With MFA and SSO rollout covering users and service account triage covering workloads, you have something real to protect in Phase 2. The next Phase 1 chapter, Conditional Access in Shadow Mode, shows how to discover what’s actually happening in your identity perimeter before you start enforcing on it. For the governance layer that keeps this program funded and accountable, see Building Your Zero Trust Governance Structure.