Named Credentials are a Salesforce feature that stores authentication details outside application code and inserts them at runtime. They help avoid hardcoded secrets and endpoints, but security depends on how narrowly the endpoint and permissions are configured. Misuse can turn a convenience feature into a broad access path for attackers.
Expanded Definition
Named Credentials are a Salesforce construct for separating authentication material from application logic so that integrations call external services without hardcoding usernames, passwords, tokens, or endpoint details in code. That boundary matters because the feature is not just a storage location; it is also a policy point that can narrow where requests go and what identity they use.
Definitions in the industry are fairly stable, but implementations vary in how tightly teams bind a credential to a specific endpoint, authentication method, or permission set. A common misunderstanding is to treat Named Credentials as automatically safe because the secret is not visible in source code. In practice, the security value comes from reducing secret exposure and constraining runtime use, not from the label itself.
For practitioners, the key boundary is that a Named Credential should represent one intended integration path, not a reusable shortcut for many systems. If the endpoint scope is broad or the connected account is over-privileged, the abstraction can hide risk instead of removing it.
Examples and Use Cases
Named Credentials typically appear where Salesforce must reach another system securely while keeping configuration separate from Apex or other application code. They are common in integration patterns that need authenticated API calls, predictable endpoint management, and cleaner secret handling.
- A Salesforce app calls a payment, ticketing, or enrichment API and uses the Named Credential to inject authentication at runtime.
- A team replaces hardcoded API keys in custom code with a centrally managed credential so rotation is less error-prone.
- An org uses different credentials for test and production endpoints to reduce accidental cross-environment access.
- A managed package or internal extension relies on one credentialed callout path instead of embedding connection details in multiple classes.
- A platform team narrows access by creating separate Named Credentials for distinct external services rather than reusing one broad integration identity.
The main tradeoff is convenience versus blast radius. A shared credential is easier to maintain, but it can also make it harder to isolate which integration has access to which service if the configuration is not kept deliberately narrow.
Security Implications
Misconfigured Named Credentials can create a false sense of safety. If teams assume that moving a secret out of code is enough, they may overlook the permissions attached to the connected identity, the scope of the target endpoint, or who can modify the credential configuration.
That matters because compromise can occur through several recognized mechanisms: overbroad API permissions, endpoint reuse across systems with different trust levels, and exposure of the integration account through related configuration or operational tooling. Once an attacker gains control of a privileged integration path, they can often act with the same authority the integration was granted, which can widen lateral movement or data access beyond the original application boundary.
NHIMG research on non-human identity risk reports that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which is a useful reminder that machine-facing credentials are often managed less rigorously than expected. For Salesforce teams, the observable warning sign is usually not a visible exploit but an integration identity that can do far more than the specific callout requires.
Domain and Governance Relevance
In the Salesforce domain, Named Credentials sit at the intersection of application integration, access governance, and secret handling. They shape how external trust is expressed in the platform, which makes them materially relevant to least privilege, endpoint governance, and separation of duties.
For non-human identities, the concept becomes especially important because the credential is often the machine identity itself. That means inventory, ownership, scope review, and rotation are not abstract administration tasks; they are the control points that determine whether an automated integration remains a bounded service account or becomes a standing broad-access path.
Teams that manage Salesforce integrations well usually treat each Named Credential as a governed asset with a clear purpose, a limited target, and a known owner. When those three elements drift apart, the feature stops being just a convenience mechanism and starts becoming a hidden trust dependency.
Risk and Threat Considerations
Named Credentials concentrate risk when they combine stored authentication, reusable endpoints, and broad connected-account permissions. The main danger is not secret visibility in source code alone, but the downstream access that a compromised or over-scoped integration identity can unlock.
Failure mechanism: The risk materialises when an attacker abuses the integration path itself, either by stealing the underlying secret, exploiting excessive permissions, or leveraging a configuration that allows the credential to reach more systems than intended. This is a recognised trust-abuse pattern in machine identity security.
Impact: The result can be unauthorised API access, data exfiltration, unwanted state changes in connected systems, or persistence through a trusted automation channel that defenders may monitor less closely than user accounts.
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 CIS Controls v8 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 — Secrets and Credential Management | Named Credentials store machine secrets and tokens outside code. |
| Recommendation — Limit each integration credential to one purpose and rotate it on a defined schedule. | ||
| CIS Controls v8 | 6 — Access Control Management | The term depends on restricting who and what can use the integration identity. |
| 16 — Application Software Security | Named Credentials shape how application code reaches external services safely. | |
| Recommendation — Enforce least privilege for connected users and remove unused integration access promptly. Treat callout configuration as controlled application security configuration, not embedded code. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | The feature exists to keep secrets out of source code and runtime exposure. |
| Recommendation — Hunt for exposed integration secrets and replace any credential found in code or logs. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Named Credentials enforce authenticated access to external systems. |
| Recommendation — Apply least-privilege access rules to every external integration identity. | ||
Practitioner Guidance
Why practitioners should care: Named Credentials should be reviewed as part of integration governance, not just development hygiene. The practical question is whether each credential maps to one business-purpose path with a tightly bounded identity and endpoint.
Common misunderstanding: Hiding secrets outside code does not make the integration safe by default. If the connected user or token has broad authority, the security posture is still determined by privilege scope and change control around the credential.
Governance implication: Assign clear ownership for each Named Credential, and treat its scope, rotation, and endpoint target as controlled configuration rather than incidental setup.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
