--- title: "Security tokens" url: "https://trailassembly.com/salesforce-security-tokens/" topic: "Admin and Permissions" published: "2026-09-21T10:34:31+00:00" updated: "2026-10-06T14:00:18+00:00" --- # Security tokens **Short answer:** a security token is a case-sensitive string Salesforce emails to a user, appended to their password when authenticating to the API from an untrusted network. It resets whenever the password changes, the new value goes to the user’s email address, and nobody tells the integration. That is the entire reason integrations built on username and password keep breaking, and the fix is to stop using them. ## What the token is for When a client authenticates with a username and password rather than an OAuth flow, Salesforce wants a second factor tied to something the account holder controls. The token is that factor. The client sends password plus token concatenated, with no separator. It is not required when the login comes from an IP inside the org’s trusted IP ranges, which is why the same integration works from the data centre and fails from a developer’s laptop. It is never required for the ordinary web login. ## Where it comes from and when it changes - A user resets their own token from personal settings, under Reset My Security Token. The new value arrives by email immediately and the old one stops working at once. - Changing the password resets the token automatically. So does an administrator resetting the password. - Password expiry policies therefore break integrations on a schedule. Every ninety days, quietly, at whatever hour the expiry lands. - The token is not visible anywhere in Setup. If the email is lost, the only option is to reset it again, which means the email address on the integration user must be a monitored mailbox. That last point is where most of the pain comes from. The integration user’s email is frequently a personal address belonging to someone who left, or a no-reply address that discards everything. Then the password expires and the token cannot be recovered without touching the account. ## The common failure modes The error is usually the same regardless of cause: an invalid username, password or token message, offering no clue which of the three is wrong. Work through them in order. - **The password was changed or reset.** Most likely cause. Reset the token and update the stored credential. - **The token was appended with a space or a separator.** It concatenates directly onto the password with nothing between. - **Login IP ranges on the profile.** These block the login outright rather than demanding a token, and produce a different but equally unhelpful message. - **The user lacks API Enabled.** No token will help. - **Wrong endpoint.** A sandbox login against the production endpoint fails in a way that reads like a credential problem. - **Password expiry on the integration user.** Set integration users to never expire, deliberately and with a compensating control, rather than discovering this monthly. ## Why this whole mechanism is on the way out Salesforce has been steadily closing down the OAuth username-password flow, disabling it by default in newer orgs and pushing customers off it. The direction is unambiguous: username, password and token is not an authentication method you should be building anything new on. The replacements are better in every respect that matters operationally. - **JWT bearer flow** with a connected app and a certificate. No password, no token, no expiry surprise. This is the default answer for server-to-server integrations. - **Web server flow with a refresh token** where a human authorises once and the refresh token persists. - **Named credentials with an external credential** for anything calling out of Salesforce, so the platform holds the secret rather than a custom setting. Migrating is a day of work per integration and removes an entire category of incident permanently. It is one of the few security improvements that also reduces support load. ## If you are stuck with tokens for now Put the integration user’s email on a shared mailbox the team monitors. Turn off password expiry for that user and record why. Store the credential in a secret manager, not in a custom setting or a config file in the repository. Keep a short runbook naming who can reset the token and how long the change takes to propagate, because the day it breaks is not the day to work that out. ## Frequently asked **Can an admin see a user’s security token?** No. Nobody can read it after the email is sent. It can only be reset. **Do trusted IP ranges remove the requirement?** Yes, for logins from those addresses. Login IP ranges on the profile are a different setting that blocks logins entirely, and the two are constantly confused. **Does MFA replace the token?** They address different paths. MFA applies to interactive logins. The token applies to API logins with a password. **What should a new integration use?** JWT bearer flow with a dedicated integration user and the narrowest permission set that works. --- Source: https://trailassembly.com/salesforce-security-tokens/ Trail Assembly — independent Salesforce write-ups.