What Happened
LastPass disclosed that attackers accessed customer data in its Salesforce environment using compromised OAuth tokens from Klue, a market intelligence platform. The breach exposed standard business contact information and CRM records—not customer password vaults. Klue traced the compromised credential to a token created for a limited pilot project in 2022 that was never deprovisioned.
Timeline
The public timeline remains limited, but the sequence matters:
2022: Klue creates OAuth credential for LastPass pilot integration project
[Unknown date]: Pilot project ends; credential remains active
[Unknown date]: Attackers compromise Klue's environment
[Unknown date]: Attackers use stolen OAuth token to query LastPass Salesforce data
[Disclosure date]: LastPass notifies affected customers
The gap between credential creation and breach highlights a fundamental control failure: your team created a time-bound integration credential, completed the project, and never revoked access.
Which Controls Failed or Were Missing
No credential lifecycle management. Klue created an OAuth token for a pilot project in 2022 and left it active indefinitely. When you issue credentials for temporary integrations, you need automated expiration or manual review triggers. Neither existed here.
Missing least-privilege scoping. The OAuth token had sufficient permissions to query customer CRM data. For a pilot project, read-only access to a test dataset should have been the ceiling. Production data access requires production-level justification.
No third-party access monitoring. LastPass's Salesforce environment accepted API calls from the Klue token without alerting on unusual query patterns, volume, or timing. Your SIEM should track third-party API activity separately from internal user sessions.
Inadequate vendor security assessment. The integration decision happened without sufficient evaluation of Klue's own security posture. When you grant a vendor OAuth access to production systems, you're extending your attack surface to include their infrastructure.
No OAuth token rotation policy. Long-lived tokens create long-lived risk. The credential existed for at least two years before compromise. Mandatory rotation every 90 days would have invalidated the attacker's access.
What the Relevant Standards Require
ISO/IEC 27001:2022 Annex A.5.19 (Access control for supplier relationships) requires you to define and implement access control requirements for third-party access, including credential management and monitoring. This wasn't a Klue security failure alone—LastPass owned the decision to grant and maintain that access.
NIST 800-53 Rev 5 AC-2 (Account Management) explicitly requires you to "review accounts for compliance with account management requirements quarterly." A 2022 credential active in 2024+ fails that test.
SOC 2 Type II CC6.1 (Logical and Physical Access Controls) requires you to restrict logical access through the use of access control software and rule sets. OAuth tokens that grant vendor access to customer data fall squarely within this control. Your auditor will ask: How often do you review third-party tokens? What triggers revocation? How do you validate continued business need?
PCI DSS v4.0.1 Requirement 8.2.2 states that authentication credentials for third-party access must be managed, including deactivation when no longer needed. If LastPass processes payment data anywhere in the environment accessible via that Salesforce integration, this becomes a direct compliance violation.
The common thread: standards don't just require you to issue credentials carefully—they require you to manage them continuously.
Lessons and Action Items for Your Team
Audit your OAuth tokens this week. Pull a report of every active OAuth token, API key, and service account credential with external access. For each one, document: Who requested it? What business function does it serve? When was it last used? Who owns the renewal decision? Revoke anything without clear current justification.
Implement automatic expiration for integration credentials. Set a 90-day maximum lifetime for any OAuth token granted to a third party. Force the business owner to reauthorize—don't auto-renew. Use your identity platform's built-in expiration features (Okta, Azure AD, Google Workspace all support this).
Scope tokens to minimum viable permissions. Never grant a pilot project the same access level as a production integration. Create separate Salesforce permission sets for vendor integrations and limit them to specific objects and fields. Read-only should be the default; write access requires executive approval.
Monitor third-party API activity separately. Configure your SIEM to alert on OAuth token usage patterns: first use after 30+ days dormant, queries exceeding normal volume, access outside business hours. Tag vendor credentials distinctly from employee sessions so you can track them independently.
Add OAuth hygiene to your vendor security questionnaire. Before granting any vendor API access, require them to document: credential rotation policy, MFA requirements for credential management, logging and monitoring capabilities, breach notification SLA. Make OAuth token security a deal-breaker, not an afterthought.
Create a third-party access review board. Quarterly, convene security, compliance, and business stakeholders to review every active vendor integration. Force the business owner to justify continued access. One "we're not using that anymore" discovery pays for the meeting.
The Klue-LastPass breach wasn't sophisticated. No zero-day exploit, no social engineering campaign. An old credential sat in a system until someone stole it. Your OAuth tokens represent persistent access to your most sensitive systems. Treat them like the long-lived vulnerabilities they are.
