Your compromised-account playbook probably starts with contacting the user to verify unusual activity, like a 2:00 am sign-in. But there's no equivalent step for a service account, an API key in a build pipeline, or an OAuth token granted to a SaaS integration years ago. Nobody replies, and your analysts are following a script meant for people.
This guide examines recent breaches and research on machine identity incidents, and what your team should change in response.
Understanding the Data
CyberArk's research shows there are about 82 machine identities for every human identity. Few have multi-factor authentication, and many have more access than needed. Their traffic often blends into the background noise that your monitoring systems filter out.
Three public incidents reveal a pattern: a credential issued for a task, then forgotten long after the task ended. None required a sophisticated attacker to exploit.
Key Findings
1. Forgotten credentials are the entry point, and rotation programs miss them.
Cloudflare rotated thousands of credentials after the Okta support breach but missed one access token and three service account credentials. Attackers used these in the Thanksgiving 2023 incident. The alert came over a week after their first login, when a service account was added to an admin group. Your rotation list is only as good as your inventory.
2. Legacy test objects carry production privileges.
Microsoft's guidance on the Midnight Blizzard attack describes a password spray against a legacy test account with no MFA. An old test OAuth app still had elevated access to the corporate environment, allowing attackers to reach corporate email accounts. Decommissioning is a security control, not just housekeeping.
3. Third-party tokens extend your blast radius to someone else's breach.
In August 2025, attackers obtained OAuth tokens from Salesloft's Drift chatbot to access Salesforce. For ten days, they pulled records from multiple customer instances. Google's threat intelligence team found the attackers were mainly after credentials, searching the stolen data for AWS access keys and passwords. Your incident scope must include credentials stored in data an integration can access.
4. Human-centric detection logic has nothing to compare against.
An attacker with a valid token makes authenticated calls to the same endpoints the integration uses daily. A patient attacker sticks to usual hours. Impossible-travel rules assume people move between cities.
5. Containment is a business decision, not just a security one.
Locking out a user costs one employee an afternoon. Revoking a credential a payments integration depends on can take a customer-facing service down. Without pre-agreed authority, analysts search for a senior approver while the attacker continues.
Implications for Your Team
Every playbook step assuming a person can be contacted, reached by a manager, or locked out cheaply needs a machine-identity counterpart. Ownership lookup, verification, containment, and scoping each change shape.
The compliance angle is clear. ISO/IEC 27001:2022 Annex A controls 5.24 (incident management planning and preparation) and 5.26 (response to information security incidents) require documented, role-assigned procedures. A procedure stating "contact the user" for an identity with no user is a gap an auditor can raise. Control 5.9 (inventory of information and other associated assets) and 5.16 (identity management) cover the inventory work. On the SOC 2 side, CC7.3 and CC7.4 cover evaluating and responding to security events, and your evidence is stronger if the playbook shows distinct handling for non-human identities. For regulated critical infrastructure entities, a 12-hour window for reporting a significant cyber incident to ASD can be running while an approval conversation drags on.
Action Items by Priority
Priority 1: Build the inventory that the playbook depends on.
Don't settle for an Active Directory export with blank description fields. For each high-privilege non-human identity, record the owning team and a brief statement of what breaks if the identity is removed. This requires a conversation with the application team. Have that conversation now, not at 3:00 am during an incident.
Priority 2: Tier identities by blast radius and name the approver.
A read-only reporting token and a cloud admin service principal shouldn't share a response path. For the top tier, assign a named role in the playbook with authority to revoke immediately, even if it breaks something. Leaving the decision to whoever is on shift results in a delay while the token remains active.
Priority 3: Replace "was this you?" with log-answerable triage.
Compare where the credential normally authenticates from against its current location. Ensure audit logging is enabled for your cloud audit logs and workload identity platforms before an incident. Compare held permissions against those used recently, as attackers target high-risk scopes sitting idle. Check for persistence: a compromised privileged service principal can mint new secrets or register a new app, and none of that disappears when you revoke the original credential.
Priority 4: Write separate triggers for rotation and revocation.
Rotate when you're confident the attacker hasn't escalated and the integration can't be lost. Revoke when there's evidence of an active attack. Write the criteria clearly to avoid debates at midnight.
Priority 5: Pre-stage replacement credentials.
Have each owning team practice generating a new credential and storing it in the secrets manager during a low-traffic week. Done in advance, revocation costs minutes of downtime instead of a day. It also exposes runbooks pointing at a vault location renamed last year.
Priority 6: Scope across the full credential lifespan.
Don't start the timeline at the alert. Machine credentials can be compromised for months before detection, so the first unusual activity you see is rarely the first unusual activity. Check what the identity can access and whether anyone has stored credentials in it; each secret you find adds a rotation to your list.
Priority 7: Fix the cause during recovery.
If a static secret was stolen, consider whether the workload can use short-lived tokens through Workload Identity Federation, or just-in-time credentials that expire automatically. This work may need budget from outside the SOC.
Priority 8: Run a tabletop with application owners present.
Pick your highest-privilege integration and simulate a stolen token from first alert to recovery. Time how long it takes the room to agree who approves a production-impacting revocation. That number tells you more about your readiness than the playbook text does.
