Skip to main content
Identity Authority
Category: Authentication Factors

Look-Up Secret

Also known as: Lookup Secret
Simply put

A look-up secret is a set of pre-generated codes that a person keeps and uses to prove their identity when logging in. Instead of remembering the code, the user selects or enters one from a stored list, such as a printed sheet or a securely held file, when prompted. The evidence available here is limited, so specific implementation details cannot be confirmed.

Formal definition

A look-up secret is a possession-based authentication factor consisting of a secret value that is stored and retrieved at authentication time rather than memorized. In the evidence provided, this is illustrated by an automation step that securely retrieves a secret from a vault and stores it in a variable for use. Beyond this, the evidence does not define standardized behavior, entropy requirements, single-use versus reusable properties, or governing specifications, so those aspects are out of scope for this entry and should not be inferred from the material at hand.

Why it matters

Look-up secrets represent a distinct approach to authentication because they rely on possession of a stored value rather than something the user memorizes. This matters for architects and IAM engineers weighing factor types, since a possession-based secret that is retrieved at authentication time behaves differently from a memorized knowledge factor in terms of how it is provisioned, stored, and protected. Understanding where a factor sits in the possession/knowledge/inherence taxonomy is foundational to designing sound multi-factor strategies.

The evidence available here is limited and does not establish standardized entropy requirements, single-use versus reusable behavior, or a governing specification for look-up secrets. As a result, practitioners should treat vendor and deployment claims about a given look-up secret implementation as configuration-specific rather than assuming uniform properties across products. Where a look-up secret is reusable, its security posture differs meaningfully from a single-use code, and that distinction directly affects threat modeling around interception and replay.

Because the concept intersects secret storage and retrieval, the operational security of the store itself becomes central. In the automation context reflected in the evidence, a secret is retrieved from a vault at runtime, which shifts part of the trust boundary onto the vault and the access controls governing it. Teams evaluating look-up secrets should therefore scope their review to include how the underlying secret is generated, stored, transmitted, and rotated in their specific deployment.

Who it's relevant to

IAM engineers and security architects
Those designing authentication flows need to place look-up secrets correctly within the possession-factor category and decide how they combine with knowledge or inherence factors in a multi-factor scheme. They should confirm implementation-specific properties, such as whether codes are single-use, rather than assuming standardized behavior the evidence does not support.
Automation and platform engineers
Teams building automated workflows may encounter look-up secrets retrieved from a vault at runtime, as reflected in the evidence. They are responsible for securing the retrieval path and the variable holding the secret, since the trust boundary extends to the vault and its access controls.
Compliance officers and auditors
Reviewers assessing authentication controls should scope evaluations to the specific deployment, verifying how the underlying secret is generated, stored, and rotated. Because the evidence establishes no governing specification or entropy requirement, claims about a look-up secret's strength should be validated against the actual configuration and vendor documentation.

Inside Look-Up Secret

Pre-generated secret set
A look-up secret is typically a set of secrets generated and issued to a subscriber during enrollment, from which the subscriber presents one selected value during authentication. Common examples include printed recovery codes or grid-card style challenge-response tables.
Possession-based authentication factor
It functions as a 'something you have' (possession) factor in most treatments, since the subscriber must retain access to the stored list of secrets rather than recalling knowledge or presenting an inherence factor.
Selection or challenge mechanism
Authentication generally involves the verifier prompting for a specific secret from the set (for example, by index or coordinate) or accepting any single unused secret, depending on the implementation.
One-time or single-use semantics
In most deployments each individual secret is intended to be used once and then marked as consumed, so that a captured value cannot be replayed after use.
Verifier-side stored representation
The verifier retains a representation of the valid secrets to check presented values. Depending on configuration this may be a hashed or otherwise protected form rather than plaintext, though protection details vary by implementation.

Common questions

Answers to the questions practitioners most commonly ask about Look-Up Secret.

Is a look-up secret the same as a one-time password (OTP) generated by an authenticator app?
No. A look-up secret is a pre-generated value that the user stores and retrieves (for example, from a printed list or file) to prove possession during authentication, whereas an OTP from an authenticator app is typically computed on demand from a shared seed or counter. Both are possession-based authenticators, but a look-up secret is a static, pre-issued value that is consumed when used, not an algorithmically derived code that regenerates over time. The distinction matters when mapping to assurance requirements, since the two have different generation, storage, and replay characteristics.
Can look-up secrets serve as a primary, standalone authentication method for a session?
In most deployments they are not intended as a primary authenticator for routine sign-in. Look-up secrets are typically positioned as a recovery or backup mechanism, or as one factor within a multi-factor flow, rather than as the everyday means of authentication. How they may be combined with other factors depends on the assurance profile and vendor configuration. Treating them as a sole authentication method for ongoing access is generally outside their intended scope.
How should look-up secrets be generated and distributed to users?
Look-up secrets are typically generated as a set of unique, high-entropy values and delivered to the user through a channel appropriate to the deployment, such as display at enrollment for the user to record or a downloadable file. The exact generation parameters, entropy, and delivery method depend on the standard profile and vendor implementation. Establishing that the values are unpredictable and issued to the correct enrolled identity is the core concern.
How is single-use enforced so that a look-up secret cannot be replayed?
Typically each look-up secret is marked as consumed once it has been successfully presented, so it cannot be accepted again. This generally requires the verifier to maintain per-secret state tracking which values remain valid. The specific enforcement and any rate-limiting on failed attempts depend on configuration, and confirming that a used value is reliably invalidated is important for preventing reuse.
How should look-up secrets be stored on the verifier side?
As with other secrets, verifiers generally avoid storing look-up secret values in a directly recoverable form and instead retain a protected representation sufficient to validate a presented value while limiting exposure if the store is compromised. The precise storage protections depend on the implementation and applicable profile. Note that protecting the stored form addresses confidentiality at the verifier and is separate from how the values are protected in transit.
What should the process be when a user exhausts or loses their look-up secrets?
Deployments typically define a replenishment or re-enrollment path, since consuming or losing the set can otherwise lock the user out of the flow that relies on it. This often involves re-establishing identity to the assurance level required before issuing a new set and invalidating any prior values. The exact recovery workflow, including thresholds for prompting reissuance, depends on the governance policy and vendor configuration.

Common misconceptions

A look-up secret is a knowledge factor because the user 'looks up' and types a code.
It is typically classified as a possession (something you have) factor, because security depends on the subscriber physically retaining the issued list of secrets rather than memorizing them. The act of reading a value from a stored list does not make it a knowledge factor.
Using a look-up secret automatically makes an authentication flow multi-factor.
A look-up secret is a single factor. It only contributes to MFA or 2FA when combined with a factor of a different type, such as a password (knowledge) or biometric (inherence). On its own it provides single-factor authentication.
Look-up secrets provide the same phishing and replay resistance as FIDO2/WebAuthn authenticators.
Look-up secrets are shared, transcribable values that can be phished or captured if a user is deceived into entering them on a malicious site. Unlike WebAuthn/FIDO2, which use origin-bound public-key cryptography, look-up secrets generally offer no cryptographic phishing resistance and rely on single-use semantics to limit replay.

Best practices

Treat look-up secrets as a possession factor and pair them with a distinct factor type (knowledge or inherence) when multi-factor assurance is required, rather than relying on them alone.
Enforce single-use semantics by marking each secret as consumed after successful authentication so captured values cannot be replayed.
Store verifier-side representations in a protected form (for example, hashed) rather than plaintext where the implementation supports it, and confirm what protection the vendor actually provides.
Provision an adequately sized set of secrets and support secure regeneration or reissuance when the set is depleted or suspected of compromise.
Prefer stronger, phishing-resistant options such as FIDO2/WebAuthn for primary authentication where available, and position look-up secrets primarily as a backup or recovery mechanism.
Deliver and instruct users to store the secret list securely, since the assurance of this factor depends on the subscriber retaining exclusive possession of the issued values.
Promotional banner for the Penetration Report Template Kit