When a machine credential is compromised, the first response decision can be harder than the technical fix. A stolen employee account has a person attached to it; a service account, API key or OAuth token may have no clear owner, no documented purpose and a production dependency that makes immediate revocation risky. That gap gives an attacker time and leaves responders making business impact decisions during an incident.
Machine identities are also numerous. CyberArk research puts them at roughly 82 for every human identity. Many lack multi-factor authentication, and some have permissions far beyond their workload’s needs. Their routine traffic can blend into the background activity that monitoring systems are tuned to suppress. A response plan designed around employees and interactive logins will miss those differences.
Why familiar incident steps break down
For a human account, an analyst can contact the user and ask whether a sign-in was legitimate. A service account can’t answer. Nor can an API key embedded in a build pipeline or an OAuth token granted to a SaaS integration years ago. Analysts have to establish what the identity does, which team owns it and what will fail if it’s disabled.
That investigation often starts with incomplete records. An account description may be blank, its application team may have changed, or the original owner may have left the company. Until responders identify someone who understands the dependency, they can’t confidently choose a containment step.
Revocation can carry a real operational cost. Disabling a compromised employee account may inconvenience one person; withdrawing a credential used by a payments integration could interrupt a customer-facing service. If nobody has agreed in advance who can accept that risk, analysts may wait for approval while the credential remains active.
Detection also needs a different frame of reference. An attacker using a valid token can call the same endpoints as the legitimate integration, perhaps at its usual time of day. Rules built to spot a person signing in from an unexpected country may have little value when the identity is a workload that never travels.
Figure 1: One alert split into two paths.
Ashish Mishra
Breaches expose the cost of forgotten credentials
Several prominent incidents show how machine credentials can outlast the work they were created to support. In Cloudflare’s Thanksgiving 2023 incident, attackers used one access token and three service account credentials stolen in an earlier Okta support breach. Cloudflare had rotated thousands of credentials after that breach, but missed these four because the team believed they were unused. The alert came more than a week after the attackers first logged in, when they added one service account to an administrator group. Cloudflare’s incident account illustrates why an assumption that a credential is dormant needs verification.
Microsoft’s Midnight Blizzard response involved a neglected test environment. The attackers used password spraying against a legacy test tenant account without MFA. An old test OAuth application in that tenant still had elevated access to the corporate environment, which the attackers then used to reach corporate email accounts. Microsoft’s guidance for responders points to the risk of treating test applications and tenants as isolated after their original purpose has faded.
The Salesloft Drift campaign showed how an integration can become a route to other credentials. In August 2025, attackers obtained the OAuth tokens used by the Drift chatbot to connect to Salesforce. For roughly ten days, they accessed records in customer Salesforce instances. Google’s threat intelligence team said the attackers were primarily seeking credentials; after extracting data, they searched it for AWS access keys, passwords and other material that could enable further access. Google’s analysis of the campaign underscores why investigation must include the data an identity could reach, not just the system where it was first detected.
Across these cases, the recurring weakness was a credential that remained active after its purpose or ownership had become unclear. A usable playbook therefore depends on maintaining identity records before an alert arrives.
Build the inventory around impact and ownership
For each high-privilege non-human identity, record the responsible team and a short explanation of what would stop working if the identity were removed. That second detail takes effort: application owners may need to confirm the dependency. But gathering it during business hours is far easier than asking an analyst to trace an undocumented credential in the middle of an active intrusion.
Rank identities by the potential damage they could cause and the disruption their removal could create. A read-only reporting token should not follow the same response path as a cloud administrator service principal. For the highest-impact credentials, name the role authorized to approve immediate revocation, including when revocation could affect production. Senior leaders should own that trade-off; leaving it to an on-call analyst invites delay at the moment speed matters.
Make triage answerable from evidence
Replace “Was this you?” with questions the logs can answer. Where does this identity normally authenticate, and where is it appearing now? Which services and resources has it accessed? Cloud Audit Logs and workload identity platforms can supply useful evidence, provided logging was enabled before the incident.
Compare the identity’s assigned permissions with the permissions it has actually used over recent months. Unused high-risk scopes deserve attention because an attacker may target privileges that have been granted but rarely exercised. Look for persistence as well: someone with access to a privileged service principal may create new secrets or register another application. Revoking the original credential won’t remove those additions.
Prepare containment and recovery before an alert
Define clear conditions for rotating a credential and for revoking it. Rotation may fit when responders have reason to believe the attacker hasn’t escalated and the business depends on the integration. Evidence of ongoing malicious activity should trigger revocation under the playbook’s pre-agreed authority. The decision criteria need to be specific enough that an incident team isn’t debating them at midnight.
Test replacement credentials in advance. Application owners should know how to create a new credential, store it in the approved secrets system and update the workload. Practicing the process during a low-traffic period can turn a disruptive outage into a brief interruption. It also exposes stale instructions, such as a vault location that has changed.
During scoping, examine the credential’s full history, not only activity after the alert. A machine identity may have been abused for months before anyone noticed, so the first suspicious event found by monitoring may not be the attacker’s first action. Track changes to permissions and newly added secrets, then include every affected credential in the rotation plan.
Recovery should address why the credential was exposed and whether the workload can use a safer pattern. A static secret may be replaceable with short-lived tokens through Workload Identity Federation or with credentials generated just in time and allowed to expire. These changes can require application work and funding beyond the security team’s control, so they belong in the recovery plan rather than as an afterthought.
Finally, run a tabletop exercise with the SOC and application owners. Choose the highest-privilege integration and walk through a stolen-token scenario from alert to recovery, including a production-impacting revocation. Measure how long it takes to identify the decision-maker and locate the replacement credential process. That rehearsal reveals whether the written playbook can guide a real response—and whether the organization can act before a forgotten machine identity opens another path inside.
