Skip to main content
Identity Authority
Category: Authentication Factors

Single-Factor Cryptographic Software

Also known as: Single-Factor Cryptographic Software Authenticator, Single-Factor Software Cryptographic Authenticator, Single-Factor Software Certificate
Simply put

Single-Factor Cryptographic Software is a type of authenticator that relies on a secret cryptographic key kept in software on a device, such as a file stored on disk. A user proves their identity by having the software demonstrate control of that key, without needing a second factor like a password or fingerprint. Because the key lives in ordinary software storage rather than dedicated hardware, it is generally considered easier to copy than a hardware-based equivalent.

Formal definition

In NIST SP 800-63B terminology, a Single-Factor Cryptographic Software authenticator consists of a secret cryptographic key and associated software stored on a software-accessible medium (for example, on disk or other "soft" media). It satisfies a single possession factor (something you have); authentication is accomplished by proving control of the key, typically through a cryptographic challenge-response protocol, and no additional factor is required. It is distinct from a single-factor cryptographic device, where the key is bound to dedicated hardware and is less readily exportable. Per SP 800-63B, cryptographic authenticators used at AAL1 are required to use approved cryptography. Microsoft Entra maps this authenticator to a single-factor software certificate. This entry addresses the authenticator type only; the broader identity proofing, session management, and authorization decisions that surround its use are out of scope.

Why it matters

Single-Factor Cryptographic Software authenticators offer stronger assurance than shared secrets like passwords because authentication is accomplished by proving control of a cryptographic key through a challenge-response protocol, rather than by transmitting a reusable secret. This makes them resistant to many replay and credential-phishing techniques that plague knowledge-based factors. For organizations that need cryptographic authentication but cannot deploy dedicated hardware to every user or workload, a software-stored key provides a practical middle ground.

The central limitation follows directly from where the key lives. Because the secret cryptographic key is stored on a software-accessible medium, typically a file on disk or other "soft" media, it is generally considered easier to copy or export than a key bound to dedicated hardware. An attacker who gains sufficient access to the device or its storage may be able to exfiltrate the key and impersonate the user or workload without triggering the physical constraints that a hardware authenticator would impose. This distinction, drawn explicitly in NIST SP 800-63B between a single-factor cryptographic software authenticator and a single-factor cryptographic device, is the key consideration when architects weigh this authenticator type against hardware-backed alternatives.

Because this is a single-factor authenticator satisfying only a possession factor (something you have), it provides no independent second factor. Depending on the sensitivity of the protected resource and the applicable assurance level, deployments may need to combine it with an additional factor or select a hardware-bound alternative. Under SP 800-63B, cryptographic authenticators used at AAL1 are required to use approved cryptography, so the cryptographic implementation itself must meet that bar for the authenticator to be conformant.

Who it's relevant to

Security Architects
Architects deciding between software-stored and hardware-bound cryptographic authenticators must weigh the exportability trade-off. Because the key resides on a software-accessible medium, it is generally easier to copy than a key bound to a single-factor cryptographic device. Where key exfiltration risk is a primary concern, a hardware-backed alternative may be more appropriate; where broad, low-friction deployment matters, the software variant can be a reasonable fit depending on the assurance level and threat model.
IAM Engineers
Engineers implementing certificate-based or key-based authentication should recognize that this authenticator satisfies only a single possession factor. In Microsoft Entra, it maps to a single-factor software certificate. Deployments that require multi-factor assurance will need to pair it with an additional factor, since proving control of the software-stored key alone does not constitute MFA.
Compliance Officers
For deployments referencing NIST SP 800-63B, note that cryptographic authenticators used at AAL1 are required to use approved cryptography, and that SP 800-63B distinguishes software-stored keys from hardware-bound cryptographic devices. Verifying which variant is actually in use, and whether the approved-cryptography requirement is met, is relevant when documenting conformance to a given authenticator assurance level.
System Administrators
Administrators managing these authenticators should account for the fact that the secret key is stored as a file on disk or similar soft media. Protecting the storage medium, controlling access to the device, and managing the lifecycle of the associated certificate or key are practical concerns, since compromise of the underlying storage can expose the key that the authenticator relies on.

Inside Single-Factor Cryptographic Software

Single-factor authentication
An authentication approach that relies on exactly one factor category. For a single-factor cryptographic software authenticator, the factor satisfied is possession, demonstrated through control of a private cryptographic key, without an accompanying knowledge or inherence factor at the authenticator level.
Cryptographic authenticator
An authenticator that proves possession by performing a cryptographic operation (typically a digital signature or challenge-response) over a verifier-supplied challenge using a private key, rather than transmitting a shared secret such as a password or OTP.
Software-based key storage
The private key is stored and used within the operating environment of a general-purpose device (for example in a file, keystore, or OS-provided key store) rather than in dedicated tamper-resistant hardware. This is the characteristic that distinguishes the software variant from a hardware cryptographic authenticator.
Possession factor
The single factor being satisfied. Proof is that the claimant controls the private key. Because it is single-factor, no knowledge factor (such as a PIN) or inherence factor (such as biometric) is required to activate the key, depending on configuration.
Challenge-response / signing operation
The runtime interaction in which the verifier sends a challenge and the authenticator returns a response derived from the private key. This proves possession without exposing the key itself and helps resist replay when the challenge is fresh.

Common questions

Answers to the questions practitioners most commonly ask about Single-Factor Cryptographic Software.

Is a single-factor cryptographic software authenticator the same as multi-factor authentication?
No. A single-factor cryptographic software authenticator provides exactly one authentication factor, typically something you have (possession) in the form of a cryptographic key held in software. It does not add a knowledge or inherence factor, so it does not by itself constitute MFA or 2FA. To reach multi-factor assurance, it would need to be combined with a distinct factor, or the key would need to be protected by an activation factor in a way that changes its classification. Treat the term as describing a single possession-based factor unless your deployment explicitly layers an additional factor.
Does 'cryptographic software' authenticator mean the same thing as a hardware security key or FIDO2 authenticator?
Not necessarily. The 'software' qualifier is significant: the cryptographic key is stored and used within software on a general-purpose device rather than within a dedicated hardware boundary such as a discrete security key or a hardware-backed secure element. A hardware cryptographic authenticator holds the key in tamper-resistant hardware, which typically offers stronger protection against key extraction. Some FIDO2/WebAuthn implementations use hardware-backed key storage while others rely on software-based storage, so whether a given authenticator qualifies as software or hardware depends on where and how its key material is actually protected in that deployment.
How is the cryptographic key protected in a single-factor cryptographic software authenticator?
In most deployments the private key is stored on the endpoint and protected by the platform's available software controls, such as operating system keystores or file-level protections. Because the key resides in software on a general-purpose device, its protection depends heavily on the security posture of that device and its OS. Depending on configuration, the key may or may not be bound to hardware-backed storage; where it is not, key extraction by malware or a compromised host is a more significant threat than with hardware-based authenticators. Assess the specific key storage mechanism rather than assuming a uniform protection level.
When is a single-factor cryptographic software authenticator an appropriate choice?
It is typically appropriate where you need phishing-resistant, key-based authentication but cannot mandate dedicated hardware tokens, and where the assurance level required can be met by a single possession factor. It is often used to raise assurance above shared secrets like passwords while keeping deployment friction and cost low. It is generally less suitable where high assurance, strong resistance to key extraction, or multi-factor requirements apply. The suitability decision should follow your target assurance level and threat model rather than convenience alone.
How do I move from a single-factor cryptographic software authenticator to multi-factor authentication?
You would pair the cryptographic software authenticator, which supplies a possession factor, with a distinct second factor from another category, such as a knowledge factor or an inherence factor. Alternatively, protecting the key with a separate activation secret or biometric can change the authenticator's classification, depending on the criteria and profile you are following. Step-up authentication is a common pattern here: the software authenticator can serve routine access, with an additional factor prompted for higher-risk operations. Confirm how your identity provider counts and combines factors so the result genuinely meets MFA criteria under your governing framework.
What operational and lifecycle controls should accompany deployment of these authenticators?
Because the key lives in software on a device, lifecycle management should cover enrollment binding the key to a verified identity, revocation when a device is lost or compromised, and re-enrollment on device change. Endpoint security posture directly affects the authenticator's strength, so device hygiene and OS-level key storage integrity are part of the control set. On the runtime side, ensure your relying parties correctly validate the authenticator's signatures and, where applicable, verify key attestation if the deployment supports it. Coordinate these controls with your broader provisioning and access review processes rather than treating the authenticator in isolation.

Common misconceptions

Because it uses cryptography, a single-factor cryptographic software authenticator is multi-factor or inherently stronger than MFA.
It satisfies only the possession factor and is single-factor by definition. Cryptographic strength does not add a second factor; combining it with a distinct knowledge or inherence factor is what produces MFA.
The software variant is equivalent in assurance to a hardware cryptographic authenticator.
The distinguishing property is that keys reside in software on a general-purpose device rather than in tamper-resistant hardware. In most deployments this makes the key more exposed to extraction by malware or a compromised host, so the two are typically treated at different assurance levels.
A single-factor cryptographic authenticator is just another form of password or shared-secret authentication.
It proves possession of a private key via a cryptographic operation and does not transmit a reusable shared secret, which is a different mechanism from password or symmetric-secret authentication.

Best practices

Protect the software key store using OS-provided key storage and access controls, and restrict which processes can invoke the private key.
Treat this as satisfying only the possession factor, and combine it with a distinct knowledge or inherence factor when the use case requires multi-factor authentication.
Use fresh, verifier-generated challenges for the signing operation to reduce replay exposure, and validate the response against the registered public key.
Maintain a defined lifecycle for the key pair, including enrollment, rotation, and prompt revocation when a device is lost or compromised, coordinating this with your provisioning and deprovisioning processes.
Assess assurance requirements against the software (non-tamper-resistant) storage model, and select a hardware cryptographic authenticator where higher assurance is needed.
Log authentication events and key usage so that possession-factor compromise can be detected and reviewed, keeping runtime enforcement records distinct from governance certification records.
Promotional banner for the Pentest Readiness checklist download