Replayable second factor

Expanded Definition

A replayable second factor is any second-step authentication mechanism that can be captured once and reused to satisfy the same verification step again, including SMS one-time codes, OTPs, and some approval prompts. In NHI and IAM practice, the key issue is not whether the factor is “something you have” in theory, but whether it can be replayed by an attacker who intercepts it, coerces a user, or relays it in real time. That is why guidance increasingly distinguishes reusable challenge responses from phishing-resistant methods such as FIDO2 or certificate-backed assertions. The NIST Cybersecurity Framework 2.0 is useful here because it frames authentication strength as part of broader access control and risk reduction, even when a second factor is present.

Definitions vary across vendors when push approvals or OTPs are described as “MFA,” because the label can conceal replay risk rather than eliminate it. The most common misapplication is treating any second step as phishing-resistant, which occurs when teams equate added friction with actual resistance to capture and reuse.

Examples and Use Cases

Implementing second-factor checks rigorously often introduces user friction and operational overhead, requiring organisations to weigh convenience against resistance to interception and social engineering.

• SMS codes used for workforce login, where an attacker who performs SIM swap or message interception can replay the code within its validity window.
• Push approval fatigue attacks, where a user approves a prompt they did not initiate and the attacker immediately completes sign-in with the captured approval flow.
• OTP-based admin access for a service console, which may slow attackers but still fails if the code is phished in real time.
• Legacy recovery flows for privileged accounts, where a second factor is accepted as proof of identity even though it is not bound to the device or session.
• Operational reviews that compare current controls against the attack patterns discussed in Ultimate Guide to NHIs, especially where secrets, tokens, and service access depend on weak human-mediated verification.

For teams designing stronger authentication, NIST Cybersecurity Framework 2.0 supports the shift from generic MFA language toward access control outcomes that reduce replay exposure.

Why It Matters in NHI Security

Replayable second factors matter because attackers rarely need to defeat a control in its intended form; they only need to reuse it before it expires. In NHI environments, this is especially dangerous when service access, admin portals, and delegated tooling are protected by shared credentials or human approval workflows. NHIMG research shows that Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how often identity compromise succeeds through weak access patterns rather than outright credential cracking. When replayable factors are used to protect privileged actions, the control can create a false sense of safety while leaving takeover paths open.

This term also matters for governance because replayable factors can delay detection. A valid code, push approval, or intercepted token often looks legitimate in logs, making compromise harder to distinguish from normal use. The security outcome is not just account access, but lateral movement into secrets, pipelines, and automation. Organisations typically encounter the consequences only after an anomalous login, prompt bombing incident, or unauthorized API action, at which point replayable second factors become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do MFA implementations still fail even when a second factor is enabled?
• Second-Factor Rate Limiting
• What was the common factor in the Snowflake, BeyondTrust, OmniGPT, and DeepSeek breaches?
• Why is identity such a critical factor in securing AI agent systems?