A soft token is a software-based second factor, usually delivered through a phone or app, that generates a time-sensitive code for login. It avoids the need for a physical device and can be centrally managed, but it still depends on secure enrollment, device trust, and policy enforcement.
What makes a soft token different from a hard token?
A soft token is software, so its security posture is tied to the device and app that host it, plus the policies that govern enrollment, code generation, and account recovery. That makes it more flexible than a physical token, but also more exposed to malware, device loss, cloning of the seed, and weak support workflows.
The practical distinction is not just form factor, it is trust boundary. A hardware token keeps the second factor in a dedicated device, while a soft token depends on the integrity of a general-purpose phone or app environment. That changes how organisations think about backup, replacement, revocation, and whether the token can be centrally disabled quickly if the user or device is compromised.
How soft tokens are used in authentication flows
Soft tokens usually appear as time-based one-time passwords or similar short-lived codes during login. The user enters the code after proving knowledge of a password or after another first factor, so the token is meant to add an additional possession check without requiring a separate hardware device.
Because the code is time-sensitive, the authentication system must validate it against the correct clock window and enrolment record. If clock drift, weak enrollment, or poor binding between the token and the account exists, the second factor can become unreliable or easier to abuse. In practice, the strongest deployments treat the token as part of a broader authentication policy, not as a standalone guarantee of identity assurance.
For implementation context, practitioners often compare soft-token risk and lifecycle handling with broader identity controls described in Ultimate Guide to NHIs and with the kinds of token abuse seen in Salesloft OAuth token breach.
Security implications of software-based second factors
Soft tokens reduce dependence on physical distribution, but they increase dependence on endpoint hygiene and recovery controls. If a phone is rooted, jailbroken, cloud-backed up insecurely, or synced into an unmanaged app environment, the token seed or generated codes may be exposed even when the user thinks the second factor is isolated.
That is why soft tokens work best when enrollment is tightly bound to the intended device, recovery paths are restricted, and replacement is treated as a security event. They are also vulnerable to phishing and real-time relay attacks when the attacker can capture a code and use it immediately, especially if the organisation still accepts legacy, phishable login patterns elsewhere in the stack.
Because token material is often managed as part of a broader identity lifecycle, the operational lessons from Guide to the Secret Sprawl Challenge and token-exposure cases such as JetBrains GitHub plugin token exposure are useful reference points for understanding how quickly software-issued credentials can be abused.
Practical deployment considerations
Soft tokens are often chosen because they are cheaper to issue, easier to replace, and more convenient for users than hardware devices. That convenience only holds when administrators can still prove enrollment integrity, revoke access fast, and distinguish a legitimate rebind from an account takeover attempt.
Organizations also need to decide whether the soft token is truly the right assurance level for the protected action. For low-risk logins it may be sufficient, but for privileged access, sensitive data, or high-fraud environments, the fact that the token lives on a general-purpose device can be a meaningful limitation.
A useful comparison is with the operational patterns covered in Ultimate Guide to NHIs, Static vs Dynamic Secrets and with credential compromise scenarios in Internet Archive breach, where the key lesson is that manageability does not remove exposure, it changes where the exposure sits.
Risk and Threat Considerations
Soft tokens create a security trade-off: they are easier to deploy, but they inherit the attack surface of the device, operating system, and recovery process that host them. If attackers can steal the phone, hijack the app, intercept the code in real time, or exploit weak re-enrollment procedures, the second factor may no longer provide meaningful resistance.
Failure mechanism: The token seed, generated code, or account binding is compromised through phishing, malware, insecure backup, device takeover, or poor help-desk recovery controls, allowing the attacker to satisfy the second-factor check.
Impact: The attacker can bypass login protections, escalate to account takeover, and use the compromised session for fraud, data theft, or further internal access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Levels | Defines assurance levels for authenticator-based login, including OTP and possession factors. |
| Recommendation — Map soft-token use to the required assurance level and reject deployments that do not meet the target AAL. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Covers authentication, device binding, and access enforcement around user login. |
| PR.DS — Data Security | Applies when token material, seeds, or recovery data must be protected on devices and in backup paths. | |
| Recommendation — Align soft-token enrollment and login policy to PR.AA and enforce strong authentication controls. Protect token seeds and recovery data so device backup or compromise does not expose the authenticator. | ||
| CIS Controls v8 | 6 — Access Control Management | Requires controlled account access, MFA, and revocation discipline for authentication paths. |
| Recommendation — Use CIS Control 6 to manage MFA enrollment, access revocation, and authentication exceptions. | ||
Practitioner Guidance
What to watch for: Treat soft tokens as a policy-controlled authenticator, not just a convenience feature. The important governance question is whether you can confidently bind the token to the right device, revoke it promptly, and recover safely without creating an easier impersonation path.
Practitioner takeaway: If the recovery flow is weaker than the login flow, the soft token is not really the strongest part of the control, it is often the easiest part to bypass.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
