TL;DR: Truffle Security says Salesforce case objects are increasingly used to store plaintext credentials, API keys and debug snippets, and Google Threat Intelligence Group recommends scanning Salesforce instances for exposed secrets as attackers target support records and third-party integrations alike. CRM data now sits inside the NHI attack surface, so discovery, exposure prevention and revocation need to be governed together.
At a glance
What this is: This is a Truffle Security analysis of why Salesforce Case records have become a secret exposure hotspot, with attackers targeting support data that often contains plaintext credentials and API keys.
Why it matters: IAM, PAM and NHI teams need to treat CRM fields, third-party integrations and support workflows as part of the secrets estate, not as separate business systems.
👉 Read Truffle Security's analysis of Salesforce case records as a secret exposure hotspot
Context
Salesforce Case records are plain-text support artifacts that often collect logs, snippets and temporary credentials while teams are trying to resolve customer issues. That makes them a governance problem as much as a data-handling problem, because the same fields that help support can also store live secrets.
The article frames Salesforce as part of the broader NHI attack surface because secrets can enter CRMs through customer support, internal chatter and custom fields. The more those records are shared, exported and searched, the more they behave like a credential repository without credential controls.
Truffle Security says the immediate question is not whether secrets exist in Salesforce, but how broadly they have spread across objects, fields and integrations. That is typical for enterprise support workflows, not an edge case.
Key questions
Q: What breaks when secrets are stored in Salesforce case records?
A: Support tickets stop being ordinary business records and start acting like hidden credential stores. If those fields contain live passwords, tokens or API keys, the exposure is not just informational. It can become an active access path that survives ticket closure, export, search and downstream copying unless the credential is revoked.
Q: Why do third-party integrations increase the risk of secret exposure?
A: Third-party integrations increase risk because they often move data across systems that were never designed as credential stores. If API keys, tokens, or passwords are embedded inside application records, attackers can discover and reuse them through normal app access. The result is a data governance problem that becomes an identity problem the moment secrets can be replayed elsewhere.
Q: How do teams know whether a secret found in CRM data is still dangerous?
A: A discovered secret is still dangerous until it is verified as invalid or revoked. Detection tells you that exposure occurred, but only validation and lifecycle control tell you whether the credential can still be used. If it remains live, the finding is an access problem, not just a data-hygiene problem.
Q: Should security teams scan Salesforce exports or block secret entry first?
A: They need both, but blocking secret entry reduces future exposure while scanning finds the records already contaminated. If teams only scan, they keep discovering the same problem after the fact. If they only block, they miss historic records and integrations that already contain live credentials.
Technical breakdown
Why case records become a secret sink
Case objects are designed for unstructured support text, which is exactly why they attract secret leakage. Customers paste debug output, configuration snippets and screenshots into tickets, while agents may add temporary credentials or workarounds into the same record. Once that happens, the data no longer behaves like a ticketing field. It becomes a durable secret store inside a business system, searchable by users, exported by reports and copied into downstream tools. The risk is not just accidental disclosure. It is that ordinary case processing creates a high-density collection point for valid credentials.
Practical implication: Classify support fields by secret risk before users can store credentials in them.
How integration abuse turns CRM data into an exfiltration path
The article notes that attackers abused a third-party Salesforce integration to download large amounts of data, which shows the access path often matters more than the platform itself. A connected application can inherit broad data visibility through OAuth scopes, API access or delegated permissions, even when the core CRM is not breached directly. In identity terms, the integration becomes the weak trust boundary. If that boundary is overbroad, the attacker can move from one connected app into support records, user data and account data without needing to compromise the primary SaaS tenant first.
Practical implication: Review third-party integrations as credentialed access paths, not just application add-ons.
Why detection alone does not close the exposure window
The article’s guidance to scan exported Salesforce objects is useful, but detection only finds the secret after it has already entered a record. In NHI terms, that is late-stage visibility, not prevention. If the exposed credential remains valid, the attacker can still use it even after the ticket is discovered. That is why the issue spans discovery, validation and revocation. A support record with a live API key is not just data exposure. It is an active authentication event waiting to be reused.
Practical implication: Pair secret scanning with automated invalidation and owner-based remediation workflows.
Threat narrative
Attacker objective: The attacker wants reusable credentials and broad CRM data access that can be leveraged beyond the original Salesforce connection.
- Entry occurred through a third-party Salesforce integration that attackers used to access support data at scale.
- Credential exposure followed because Case records and related fields contained plaintext credentials, API keys and debug snippets.
- Escalation came from broad data access across Cases, Accounts, Opportunities and Users once the integration was trusted.
- Impact was large-scale exfiltration of Salesforce data and potential reuse of any live secrets found in the records.
Breaches seen in the wild
- MongoBleed breach: MongoBleed exposed secrets across 87K MongoDB servers.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Salesforce Case data has become an identity-bearing secret store. Support records are no longer just customer service artifacts when they routinely contain live credentials, API keys and debug content. That shifts CRM governance into NHI territory because the object model itself now carries authentication material. Practitioners need to treat Case fields as part of the secret estate, not as benign business metadata.
Third-party access without tight OAuth scope is the real boundary failure. The article shows that the compromise path ran through an integration layer, not through the CRM alone. That means the governance question is not whether Salesforce is secure in the abstract, but whether delegated application access is constrained to the minimum records and actions required. Integration scope is now a material part of identity risk.
Secret exposure in CRM workflows creates identity blast radius beyond the original ticket. A credential pasted into a Case can be copied, exported, indexed and reused long after the support issue is closed. The result is persistent exposure with no natural lifecycle signal, because the record is business data while the secret inside it is an authentication control. Practitioners should see support workflow design as a control surface for NHI risk.
Exposed credential detection must be paired with revocation, or the control remains partial. Truffle Security's analysis aligns with the broader pattern that discovery alone does not remove usable access. If a secret is still valid after it is found, the attacker can keep using it through whatever system accepted it. The practical conclusion is that secrets in SaaS records demand ownership, validation and revocation as one workflow.
CRM secret leakage is now a governance and hygiene problem across human, NHI and SaaS administration teams. Support engineers create the exposure, integrations amplify it, and identity teams have to contain it. That makes this a cross-domain problem rather than a single tool problem. The field needs shared ownership for where credentials are allowed to appear and who is responsible when they do.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity blast radius now extends into CRM support workflows: when credentials are pasted into Cases, the support record itself becomes part of the authentication attack surface. That means governance has to cover fields, exports and connected apps, not just dedicated secret vaults.
Support records often retain secrets long after the original issue is closed, which makes detection a starting point rather than a remedy. According to the State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that revocation is the real control boundary.
For practitioners
- Audit Salesforce fields for secret-bearing content Inventory Case, Account, User, Opportunity and custom text fields that commonly receive logs, snippets, passwords or API keys, then classify them as sensitive data paths.
- Constrain third-party integration scopes Review connected apps and OAuth grants to confirm each integration can only read the objects and fields it actually requires, with no broad export or admin-style visibility.
- Scan exported CRM data for live credentials Run secret detection against Salesforce CSV exports and only accept findings that are still verified as valid, so you can prioritise true exposure over noise.
- Block credentials from being stored in support flows Add input filtering, support guidance and form controls that prevent passwords, tokens and keys from being pasted into Cases or related custom fields.
- Tie detection to revocation ownership Assign each discovered secret to an owner and require a revocation or rotation outcome before closing the exposure case, so validation leads to disposal of access.
Key takeaways
- Salesforce Case records can function as an ungoverned secret store when users paste credentials, logs and configuration snippets into support workflows.
- The strongest evidence in the article is that real customer credentials were found in Case objects and that a third-party integration was used to access large amounts of Salesforce data.
- Teams need to combine field-level prevention, integration scope review and verified revocation so that exposed secrets do not remain usable after discovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Case records and exports are used here as a path for exposed credentials. |
| NHI-03 — Vulnerable Third-Party NHI | A third-party integration provided the access path into Salesforce data. | |
| NHI-07 — Long-Lived Secrets | The core risk is that leaked credentials can remain valid after discovery. | |
| Recommendation — Scan CRM fields and exports for leaked credentials and remove any secret-bearing data from support workflows. Review delegated app access and reduce third-party permissions to the minimum required objects and fields. Inventory exposed secrets and revoke or rotate anything that remains valid after detection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on credentials that must be rotated or revoked after exposure. |
| Recommendation — Apply authenticator lifecycle controls to exposed Salesforce credentials and revoke invalidated secrets immediately. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is overbroad access through CRM fields and connected apps. |
| Recommendation — Limit Salesforce entitlements and integration authorizations to the minimum data required for each workflow. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes credential collection and bulk data theft through a SaaS integration path. |
| Recommendation — Map Salesforce secret exposure to credential access and exfiltration activity in your detection pipeline. | ||
Key terms
- Secret-bearing support record: A support record that contains credentials, tokens, API keys or other authentication material alongside ordinary service data. In SaaS workflows, these records become hidden security assets and liabilities because they can be searched, exported and copied outside their original context.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Verified secret exposure: A secret finding that has been confirmed as still valid and therefore still usable by an attacker. This distinction matters because an old or revoked credential is a data exposure event, while a live credential is an active access risk that requires revocation or rotation.
What's in the full article
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact Salesforce object fields that were used in the scanning workflow, including built-in and custom Case data.
- Step-by-step Bulk API 2.0 and CSV export commands for extracting support records before secret scanning.
- Operational guidance for running TruffleHog in verified mode against exported Salesforce data.
- Remediation handling for exposed credentials, including deletion of exported files after review.
👉 Truffle Security's full post covers the Case scanning workflow, integration risk and cleanup steps.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org