Service Accounts, API Keys, and Bot Credentials: The Non-Human Attack Surface Your SIEM Can't See

Your SIEM is watching the front door. Attackers are walking in through the service entrance.

Every mature security team has MFA, SSO, and log aggregation. Most have invested in endpoint detection, threat intelligence, and at least quarterly access reviews. Yet breach after breach in 2024 and 2025 followed the same pattern: attackers didn't crack a password. They stole a credential that never had a password policy in the first place.

Service accounts. API keys. OAuth tokens. CI/CD pipeline credentials. Bot accounts.

These are non-human identities (NHIs) - the "workforce" that runs your automation, connects your SaaS tools, and keeps your pipelines moving. In most organizations, they're ungoverned, invisible to your SIEM, and quietly accumulating.

Service accounts are the most common type of non-human identity in enterprise infrastructure. Every CI/CD pipeline, microservice, and SaaS integration needs one - and in many organizations they outnumber human users by an order of magnitude. This isn't a niche edge case. It's the dominant shape of your identity environment, and most governance programs treat it as an afterthought.

The Scale of the Problem Nobody's Tracking

Most CISOs know their headcount. Very few know their NHI count.

CyberArk's 2025 Identity Security Landscape found 82 machine identities for every human, with 42% carrying privileged access. In a 500-person company, that's potentially tens of thousands of service accounts, API keys, OAuth tokens, and bot credentials - most created quietly by developers, operations teams, or SaaS onboarding flows - and almost none governed with the same rigor as a human employee account.

Companies pour resources into securing employee accounts with MFA, zero trust, and regular access reviews. Meanwhile, service accounts get created with static credentials, granted sweeping permissions, and left unmanaged - a growing population of identities operating outside traditional IAM controls.

The inventory problem alone is serious. The real risk is what happens to those identities when nobody's watching.

• A developer leaves. Their personal API keys to your GitHub, Snowflake, and internal tooling remain active.
• A project ends. The CI/CD service account it used - with deploy access to production - persists indefinitely.
• A SaaS integration gets replaced. The OAuth token it issued never gets revoked.
• A bot account created for a campaign two years ago still has write access to your CRM.

Service account credentials are often hardcoded in application code and checked into version control, baked into container images, or stored as long-lived tokens in CI/CD pipelines. GitGuardian's 2026 report found roughly 29 million secrets detected on public GitHub in 2025.

That's not a secrets management problem in isolation. It's a governance failure - identities created without lifecycle policies, reviewed without continuous oversight, and deprovisioned (if at all) only when someone thinks to ask.

Why Your SIEM Misses Most of This

SIEM tools are built for log correlation. They ingest events from systems that generate structured logs, look for anomalies relative to known baselines, and alert when something deviates.

The problem with NHIs: stolen credentials don't look like anomalies.

Instead of compromising user credentials, attackers replay valid OAuth tokens to authenticate directly into SaaS environments - bypassing MFA and quietly exfiltrating data over days. Because the activity originates from a sanctioned integration using valid tokens, it blends in with normal SaaS-to-SaaS traffic and evades traditional security controls.

The 2025 Salesloft/Drift breach is the clearest example. The threat actor used stolen OAuth tokens from the Salesloft Drift app to access Salesforce organizations, export data, and hunt for high-value secrets like AWS keys and Snowflake tokens. A textbook abuse of non-human identities - traditional controls like MFA were completely bypassed.

Your SIEM saw: a known integration authenticating normally. What actually happened: systematic data exfiltration.

This isn't a detection gap you can close by tuning more SIEM rules. SaaS sprawl means an explosion of OAuth tokens, API keys, and app connections - each integration introduces a non-human identity that usually isn't visible to IT or tracked by traditional identity management. The result: an ungoverned attack surface.

Detection without governance is reactive at best. You can't baseline "normal" for an identity you don't know exists.

The Real Breach Pattern: It Always Starts With a Static Credential

Look at the breach catalog from the last 18 months. The entry point is rarely a zero-day. It's almost always a poorly managed non-human credential.

Attackers stole the New York Times' source code by exploiting an over-privileged GitHub token that granted access to all repositories.

In the Cloudflare/Okta incident, although Cloudflare rotated 5,000 credentials, an unrotated token and service account credentials let hackers compromise their Atlassian environment.

85% of breaches between January and July 2024 involved compromised service accounts - a notable increase from 71% during the same period in 2023.^{1How to Fix the Authentication Token Manipulation Error?}

The pattern is consistent: service accounts are a direct path to domain dominance. Attackers use them to move laterally, escalate privileges, and access sensitive systems - all without deploying malware. Over-permissioned, under-managed service accounts are one of the most exploited yet underestimated attack vectors.

The worst part? Unlike human accounts protected by MFA and lockout policies, service accounts use static tokens with no extra verification step. A stolen credential works regardless of where, when, or how it's used.

No second factor to bypass. No lockout to trigger. The SIEM sees a valid token. The attacker has everything they need.

Why Non-Human Identities Need the Same Lifecycle Governance as Humans

The industry has spent 20 years building joiner-mover-leaver (JML) processes for human employees. Onboarding triggers provisioning. Role changes trigger access updates. Offboarding triggers revocation. It's not perfect, but at least there's a model.

Non-human identities have no equivalent. They're created with broad permissions, and the default lifecycle is: created, used, forgotten.

Here's what proper NHI governance looks like compared to what most organizations actually have:

Unlike human identities - typically centralized and managed through a single identity provider - NHIs are decentralized by nature. They're spun up dynamically across platforms, provisioned through Infrastructure-as-Code, and often created by developers, DevOps engineers, and even autonomous systems. This proliferation makes them hard to track, harder to govern, and nearly impossible to secure without the right visibility and controls.

The answer isn't a separate tool for NHIs. That creates another silo, another dashboard, and another place where coverage gaps hide. The answer is bringing non-human identities into the same governance model as humans - the same lifecycle policies, the same access reviews, the same deprovisioning discipline.

This is exactly what identity governance programs built for the modern stack do differently: treating every authenticatable principal - human or machine - as a governed identity.

What Complete NHI Governance Actually Looks Like

If you're a CISO trying to close this gap without adding headcount or a 12-month implementation project, here's what you need - and what to demand from any governance platform you evaluate.

1. Full Discovery Across Your Entire Stack

You can't govern what you can't see. A governance platform must discover NHIs across every app in your environment - not just the ones with SCIM connectors or enterprise-tier API access.

Most "modern IGA" tools stop at SCIM-enabled apps. Your CI/CD tooling, internal platforms, and legacy SaaS tools without enterprise plans still carry service accounts and API keys. A governance solution covering only 30-40% of your stack leaves the majority of your NHI attack surface invisible.

Iden's universal connectors reach apps regardless of whether they support SCIM, have APIs, or neither - so discovery is complete, not partial.

2. Ownership Assignment and Lifecycle Policies

Every NHI needs an owner: a team, a system, a purpose. Without ownership, nothing gets reviewed, nothing gets rotated, and nothing gets deprovisioned when it's no longer needed.

Good governance platforms tie NHIs to their owning human identities (or owning systems), so when an employee leaves, their associated service accounts and API tokens are caught in the same offboarding sweep - not left behind as orphaned credentials.

3. Continuous Access Reviews - Not Periodic Rubber-Stamps

Quarterly access reviews don't work for NHIs. A token can be compromised, abused, and cleaned up before your next review cycle opens.

The standard of care is continuous governance: real-time visibility into what each NHI can access, automated alerts when access drifts beyond expected scope, and policy-driven revocation when an NHI goes dormant or its owning context changes.

This is the shift from static checks to real-time decisions - the only model that keeps pace with continuous attacks.

4. Immutable Audit Logs for Every Identity

When an auditor asks "who had access to the production database, and since when?" - the answer needs to cover service accounts and API keys, not just human employees.

Immutable audit trails across all identities, with clear provenance for each access grant and revocation, turn a governance platform into a compliance asset. Without this for NHIs, your SOC 2 or ISO 27001 evidence is incomplete.

5. Automated Deprovisioning - Including the Long Tail

The hardest part of NHI governance at scale is deprovisioning. Most platforms automate offboarding for SCIM-connected apps. But your GitHub tokens, Notion integrations, and Figma bot accounts require connectors that go deeper than SCIM.

Automated, policy-driven deprovisioning that reaches every app - not just the 30% with SCIM support - eliminates orphaned accounts and zombie credentials at the source.

This is where the contractor and service account governance gap becomes most visible - any identity outside your standard HRIS-driven JML process tends to accumulate and persist.

The Security Imperative, Not Just Compliance

There's a tendency to frame NHI governance as a compliance checkbox - something you do because SOC 2 or ISO 27001 asks for access reviews. That framing undersells the risk.

Nearly one third of all cyber incidents in 2024 were identity-based attacks using valid accounts. Admin and service accounts - frequently carrying broad permissions, static credentials, and unrestricted logon rights - are some of the most powerful assets in your network and some of the toughest to secure.

Once an attacker compromises a single over-privileged service account, the damage compounds fast. The entry point is a static credential. Lateral movement is fueled by excessive permissions that were never reviewed. Dwell time stretches because nothing baselines that identity's normal behavior.

Your SIEM can't solve this. Secrets management tools help with key rotation but don't provide governance. PAM covers privileged infrastructure access but misses the SaaS layer. SSO protects interactive human logins, not the machine-to-machine traffic running underneath.

The gap is a governance gap - and closing it means treating non-human identities as first-class citizens in your identity security program.

Key Takeaways for Security Leaders

• NHIs outnumber humans by up to 82:1 in enterprise environments, yet most governance programs cover only human accounts.
• SIEM cannot detect compromised OAuth tokens or API keys that operate as trusted, sanctioned integrations - attackers blend in as legitimate traffic.
• 85% of breaches in H1 2024 involved compromised service accounts - this is not a future risk, it's your current exposure.
• Static credentials with no rotation, no ownership, and no deprovisioning are the dominant entry point for lateral movement and data exfiltration.
• Governance - not just detection - is the answer: full discovery, ownership assignment, continuous reviews, and automated deprovisioning across your entire app stack, including apps without SCIM or APIs.
• The goal is one governance layer for all identities - human and non-human - not separate tools for separate problems.