Skip to main content
Identity Authority
Category: Multi-Factor Methods

Software Token

Also known as: Soft Token
Simply put

A software token is an authentication tool delivered as an application, typically running on a smartphone or computer, that generates codes used to verify a user's identity when accessing secure systems. It serves as something the user possesses, often as part of two-factor or multi-factor authentication. Unlike a physical hardware token, it exists purely as software.

Formal definition

A software token is a software-based implementation of a possession factor used in authentication, commonly deployed as a mobile or desktop application that generates one-time passwords or otherwise proves possession during an authentication flow. In many deployments these take the form of software OATH tokens, where an authenticator application (for example, generic OATH-compliant authenticator apps) produces time- or event-based codes. Software tokens contrast with hardware tokens by residing on a general-purpose device rather than dedicated hardware, and their configuration and distribution are typically governed by platform-specific token profiles depending on the vendor. As a possession-factor mechanism, a software token addresses authentication (verifying who the principal is) and is out of scope for authorization decisions.

Why it matters

Software tokens make possession-factor authentication practical at scale. Because they run as applications on devices users already carry, such as smartphones and computers, organizations can deploy a second factor without procuring, shipping, and replacing dedicated hardware for every user. This lowers the operational overhead of moving beyond password-only authentication and helps enterprises satisfy requirements for two-factor or multi-factor authentication across large populations.

That convenience comes with trade-offs relative to hardware tokens. A software token resides on a general-purpose device rather than dedicated hardware, so its security posture depends on the security of the host platform. In most deployments the app, its underlying secret material, and its distribution are governed by platform-specific token profiles, and the strength of the factor is influenced by how well those profiles and the host device are protected. Readers evaluating software tokens should weigh this against alternatives depending on their threat model and compliance context.

It is important to keep scope clear: a software token addresses authentication, verifying who the principal is by proving possession of a configured secret. It does not, on its own, make authorization decisions about what that principal may access. Treating a successful software-token challenge as anything more than one step in an authentication flow risks conflating identity verification with access enforcement.

Who it's relevant to

IAM Engineers
Engineers implementing two-factor or multi-factor authentication use software tokens as a possession factor that avoids the logistics of hardware distribution. They should understand that software OATH tokens rely on authenticator applications and that configuration and distribution are typically driven by platform-specific token profiles, which affect how tokens are provisioned across device types.
Security Architects
Architects choosing between software and hardware tokens must account for the fact that a software token resides on a general-purpose device rather than dedicated hardware, which ties its security to the host platform. This trade-off between deployment convenience and factor strength should be assessed against the organization's threat model rather than treated as universally better or worse.
System Administrators
Administrators responsible for rolling out authenticator apps manage software token profiles that specify configuration and distribution per platform, often requiring a distinct profile for each supported device type. Understanding this profile-driven model helps them provision and support tokens consistently across a diverse device fleet.
Compliance Officers
Officers verifying that authentication controls meet multi-factor requirements can treat software tokens as a possession factor within an authentication flow. They should note that the token verifies identity only and is out of scope for authorization decisions, and that its assurance depends on how the token and host device are protected in a given deployment.

Inside Software Token

Shared Secret or Cryptographic Seed
A software token typically stores a secret key (for example, the seed provisioned during enrollment) used to generate one-time codes. In TOTP-based implementations this seed combines with the current time to produce time-based codes, while HOTP-based implementations use a counter value instead.
OTP Generation Algorithm
The token application implements an algorithm, commonly TOTP (time-based) or HOTP (counter-based), that derives a short-lived code from the stored secret. The specifics depend on the profile and vendor configuration.
Software Application or Container
Unlike a hardware token, a software token runs as an application on a general-purpose device such as a smartphone or computer, or as a component within another app. This software container is responsible for protecting the stored secret.
Possession Factor Role
In an authentication flow, a software token functions as a possession factor, evidence that the user controls a particular provisioned application or device, distinct from knowledge factors (such as passwords) and inherence factors (such as biometrics).

Common questions

Answers to the questions practitioners most commonly ask about Software Token.

Is a software token the same thing as SMS-based one-time passcodes?
No. A software token is typically an authenticator application that generates one-time passcodes locally on a device, most commonly using the TOTP algorithm (and in some deployments HOTP). SMS-based OTPs are delivered over the mobile network to a phone number. Both are possession factors, but they differ in how the code is produced and transmitted: a software token derives the code on-device from a shared secret and, for TOTP, the current time, whereas an SMS code is generated server-side and sent to the user. Whether either is appropriate for a given assurance level depends on your threat model and applicable policy.
Does using a software token count as multi-factor authentication on its own?
Not by itself. A software token provides a single factor, typically a possession factor represented by the code the app generates. It becomes part of MFA only when combined with an additional factor of a different category, such as a knowledge factor (a password) or an inherence factor (a biometric). If a software token is the only factor presented, the flow is single-factor authentication regardless of how the code is generated. Note also that a software token addresses authentication only and does not determine what the authenticated principal is authorized to do.
How is the shared secret typically provisioned to a software token app?
In most deployments, the shared secret (seed) is provisioned during enrollment, commonly by displaying a QR code that encodes the secret and configuration parameters, which the authenticator app scans; manual key entry is often offered as a fallback. The security of this step matters because anyone who captures the seed can generate valid codes. Provisioning details, key length, and supported algorithms vary by vendor and by the profile the authenticator supports, so confirm what your platform and app actually implement rather than assuming defaults.
What happens to software token access when a user loses or replaces their device?
Because the seed typically resides on the device, losing the device generally means the user can no longer generate valid codes, which is why recovery and re-enrollment paths are essential. Common approaches include backup codes issued at enrollment, an alternative registered authenticator, or an administrator-assisted re-provisioning that issues a new seed. Some authenticator apps offer cloud backup or multi-device sync of seeds, but availability and security characteristics of that feature vary by vendor. Design recovery flows carefully, since they are a frequent target and can undermine the strength of the primary factor.
How should time drift between the token and the server be handled for TOTP?
TOTP codes are derived from the current time in fixed intervals, so the device clock and the validating server must be reasonably synchronized. In most implementations the server accepts a small window of adjacent time steps to tolerate minor drift, and the acceptable window is configurable. Widening the window increases usability but also increases the number of valid codes at any moment, which has security implications. Ensuring accurate time on both the device and the validating service reduces the need for a large tolerance window.
How does software token validation fit into runtime access enforcement?
Validation of the one-time passcode occurs at the authentication stage, where the service verifies that the submitted code matches an expected value derived from the stored seed and, for TOTP, the current time step. This is distinct from authorization decisions made afterward. Depending on your architecture, successful validation may result in issuing a session or a token used by downstream components, and any subsequent authorization enforcement (for example at a PDP/PEP) is a separate concern from validating the software token code itself.

Common misconceptions

A software token authenticates the user by itself.
A software token supplies a possession factor used within an authentication step; it does not, on its own, perform full identification, authentication, and authorization. It is typically combined with other factors in an MFA or 2FA flow, and the verifying system still validates the code and makes the authentication decision.
Software tokens and hardware tokens are functionally identical and equally protected.
Both can serve as possession factors, but a software token runs within a general-purpose device or application rather than dedicated hardware. Depending on the deployment, this can expose the stored secret to different threats than a hardware token, so their security properties are not interchangeable.
A software token is the same thing as passwordless authentication or a passkey.
A software token generating OTP codes is a distinct mechanism from passwordless approaches such as FIDO2/WebAuthn passkeys. Software tokens are often used as an additional factor alongside a password, whereas passkeys are designed to replace passwords; they should not be treated as synonyms.

Best practices

Provision the token secret over a secure channel during enrollment and confirm the code before activating the factor, since the security of every subsequent code depends on protecting the initial seed.
Use software tokens as one factor within an MFA or 2FA flow rather than treating a valid OTP as sufficient proof of identity on its own.
Protect the software container, for example, by requiring a device unlock or app-level protection, because the stored secret resides on a general-purpose device that may be more exposed than dedicated hardware.
Choose the OTP profile (typically TOTP or HOTP) deliberately and account for its behavior, such as time synchronization requirements for time-based codes or counter drift for counter-based codes.
Plan for lifecycle events by defining processes to re-provision tokens on device loss or replacement and to revoke the factor when a user's access is deprovisioned.
Where stronger assurance or phishing resistance is required, evaluate whether a software token is adequate or whether alternatives such as FIDO2/WebAuthn are more appropriate for the deployment context.
Application Security Isn’t Optional Anymore.