Understanding the Data
For years, compliance discussions around privileged access focused on human users. Tools like PAM platforms and MFA were designed with people in mind. However, machine identities have quietly multiplied, demanding a shift in focus. A survey by Palo Alto Networks found an average of 109 machine identities per human identity. Notably, 61% of privileged access requests still rely on standing privileges rather than on-demand grants. Entro Labs found that nearly half of these credentials are over a year old, with 7.5% between five and ten years old.
If you're preparing for a SOC 2 Type II audit or working through ISO/IEC 27001 surveillance, these statistics are directly relevant to your control environment.
Key Findings
Standing Credentials Pose Risks. Service account credentials remain valid between password rotations, creating a persistent attack surface. An attacker with early access can exploit this for months. OAuth refresh tokens exacerbate the issue, as they renew indefinitely. The Salesloft Drift incident in August 2025 highlighted this risk when attackers used stolen tokens to access data from over 700 Salesforce instances without triggering MFA alerts.
Lack of Inventory. Many organizations can't identify who owns certain service accounts. Often, the creator has left, and the credentials remain in use without oversight. This lack of inventory fails to meet CC6.1 (logical access controls) or ISO/IEC 27001 Clause 5.15 (access control) standards.
Rotation Isn't Enough. Regularly changing secrets is better than hard-coding them, but it doesn't address the underlying access. Credentials remain valid between rotations, which doesn't align with the intended control objectives.
Unapproved Vendor Integrations. Many OAuth grants were authorized long ago by business teams, often with excessive scopes. Post-Drift, auditors will scrutinize how third parties store your refresh tokens, and "we don't know" won't suffice.
Zero Standing Privilege as a Model. SOC 2 Trust Services Criteria CC6.2 and ISO/IEC 27001 Annex A.5.15 both assume temporary access granted for specific purposes. Standing machine credentials inherently fail this requirement.
Implications for Your Team
Your current controls may treat machine identities as a vaulting issue. This approach worked when service accounts were few, but with a 109:1 ratio, it's inadequate. You're managing numerous credentials with permanent access, while audits focus on human identities.
Auditors are asking tougher questions. They may request a list of service accounts with admin roles and inquire about their approval and usage history. If your PAM platform doesn't cover workloads, you'll struggle to provide answers, risking a qualified audit opinion.
The Drift incident also affects Complementary Subservice Organization Controls. If you rely on a SaaS vendor's SOC 2 report, auditors will demand proof of how the vendor manages OAuth tokens. Simply reviewing their report may not be enough if it doesn't address token storage.
Action Items by Priority
Build an Inventory. Document every machine credential, including OAuth grants. Assign a responsible owner to each. This isn't bureaucracy; it's essential for regular reviews and clean-ups. Track these in your ISMS asset register for ISO/IEC 27001 or your system description for SOC 2.
Prioritize by Risk. Sort credentials by potential impact. CI/CD pipelines and cloud admin roles are high-risk areas. Transitioning these to OIDC can be an early, strategic win.
Audit OAuth Grants. Review connected apps with access to critical systems. Limit scopes to necessary functions, document justifications, and establish a review schedule. This supports CC6.2 and Clause 5.15 compliance.
Implement Federation. Use federation where possible. For example, GitHub Actions deploying into AWS can use OIDC tokens, eliminating the need to store access keys.
Use Dynamic Secrets. For systems that can't federate, use vault-issued dynamic secrets. These create and drop accounts as needed, removing standing access.
Monitor the Ratio. Report the ratio of on-demand to permanent machine access to your board. Initial numbers may be poor, but tracking changes over time demonstrates program maturity.
