A password that works only once is worthless to an attacker who steals it after use, but not to one who relays it before. D3-OTP One-time Password is the MITRE D3FEND countermeasure built on that property: D3FEND defines it as a password "valid for only one user authentication", places it in the Harden tactic as a child of Password Rotation (D3-PR), itself under Credential Rotation and Credential Hardening, and models it as a technique that use-limits the Password artefact. This card covers what D3-OTP hardens, which ATT&CK techniques D3FEND relates to it, the HOTP and TOTP mechanics a verifier must get right, how to test it and where it fails. It is written for identity engineers and detection teams. For product and app guidance see the Authenticator Apps and OTP Guide; this card stays on the countermeasure.
Key takeaways
- D3-OTP is extreme password rotation. D3FEND files it under Password Rotation: each code is a new password that expires after one use, so a code captured after use cannot be replayed.
- It defeats guessing and reuse, not relay. D3FEND's direct mapping is T1110.001, T1110.002 and T1110.003; NIST SP 800-63B-4 states plainly that OTP authentication is not phishing-resistant.
- The verifier carries the security. Accept each code once, rate-limit failures and keep the acceptance window tight; RFC 4226 and RFC 6238 set these rules.
- Delivery and backup codes are the weak points. D3FEND's own considerations name SIM swapping, lost devices, and backup code files stolen or left in a printer spool.
- Use it as a bridge, not a destination. For privileged users move to phishing-resistant methods; keep OTP where nothing stronger is possible, with tight verifier settings.
D3-OTP at a glance
| Field | D3-OTP One-time Password |
|---|---|
| D3FEND ID | D3-OTP |
| Tactic | Harden |
| Parent technique | Password Rotation (D3-PR), under Credential Rotation (D3-CRO) and Credential Hardening (D3-CH) |
| Digital artefact | Password (D3FEND: the technique "use-limits" a Password) |
| Synonym | OTP |
| D3FEND references | NIST SP 800-63-3 Digital Identity Guidelines; IETF RFC 2289 A One-Time Password System |
| Main forms | Pre-issued list (look-up secrets, backup codes), codes sent over SMS or to an app, codes generated by a token or authenticator app (HOTP, TOTP) |
| Typical implementation points | Identity provider second factor, VPN and remote access, privileged access tools, operating system logon modules, account recovery |
| Main limitation | Codes are typed by the user, so a real-time phishing proxy can relay them within their validity window |
How it works
D3FEND describes the flow: when a user starts authentication they are asked for a one-time password, often in addition to a traditional password or a smart card. The code may come from a list issued in advance, be sent over a channel such as SMS or HTTPS to an app, or be generated by a token. A time-based hardware token does not need an internet connection, and an administrator or a user with additional verification can adjust for clock skew between token and verifier.
| Scheme | Specification and status | Moving factor | Verifier rules that matter |
|---|---|---|---|
| S/KEY style hash chain | RFC 2289, February 1998, Internet Standard (STD 61) | Sequence number counting down a hash chain from a pass-phrase and seed | Server stores only the last accepted value; must block simultaneous sessions for a user to stop the race attack; pass-phrase at least 10 characters |
| HOTP | RFC 4226, December 2005, Informational | Event counter | At least 6 digits; shared secret at least 128 bits (160 recommended); throttle failed attempts across sessions; keep the look-ahead window small |
| TOTP | RFC 6238, May 2011, Informational | Time steps (default 30 seconds) | Must not accept the second attempt of a code once validated; allow at most one time step for network delay; record per-token drift |
| Look-up secrets and backup codes | NIST SP 800-63B-4 | Position in a pre-issued list | At least six decimal digits; saved recovery codes stored hashed with an approved one-way function |
| SMS or voice codes | NIST SP 800-63B-4 (out-of-band over the PSTN) | Code sent per sign-in | Restricted authenticator: offer an unrestricted alternative, notify users of the risk and keep a migration plan |
RFC 4226 frames the residual risk for HOTP: brute force is the best attack, with success probability rising with the look-ahead window and the number of attempts and falling with the number of digits. That is why rate limiting and window size are verifier settings, not user advice.
What NIST SP 800-63B-4 requires of OTP verifiers
- Replay: "Verifiers SHALL accept a given OTP only once while it is valid."
- Key strength and output: the secret key and algorithm provide at least 112 bits of security strength; output may be truncated to as few as six decimal digits; a clock-based nonce changes at least once every two minutes.
- Rate limiting: required for multi-factor OTP and for single-factor OTP with output under 64 bits; the general ceiling is no more than 100 consecutive failed attempts before the authenticator is disabled, and organisations may set lower limits.
- Assurance levels: single-factor OTP is permitted at AAL1 and, combined with a password or biometric, at AAL2; multi-factor OTP is permitted at AAL1 and AAL2 but not AAL3.
- Phishing resistance: OTP and out-of-band authenticators shall not be considered phishing-resistant, because manual entry does not bind the output to the session. At AAL2 verifiers shall offer at least one phishing-resistant option.
ATT&CK techniques D3FEND relates to D3-OTP
Relationship type: inferred only. D3FEND links D3-OTP to ATT&CK through shared digital artefacts and labels the links inferred and experimental (checked November 2026). The direct link is through Password, which D3-OTP use-limits. The D3FEND site also shows a wider set inherited through Credential, the artefact its ancestors Credential Rotation and Credential Hardening act on. All IDs below were checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | D3FEND relation | What OTP changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1110.001 | Password Guessing | Direct: accesses Password | Strong: a guessed static password is not enough, and guessing the code is bounded by rate limiting |
| T1110.002 | Password Cracking | Direct: accesses Password | Strong: a cracked hash of a used code has no value; the static password alone no longer completes sign-in |
| T1110.003 | Password Spraying | Direct: accesses Password | Strong on OTP-protected paths; none on paths that accept the password alone |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Inherited via Credential | Partial: dumped static hashes still work on protocols that never ask for the code |
| T1558.001 | Golden Ticket | Inherited via Credential | Minimal: forged tickets are presented after authentication |
| T1606.001 | Web Cookies | Inherited via Credential | Minimal: forged cookies stand in for a completed sign-in |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie | Inherited via Credential | Minimal: these bypass the authentication step that asks for the code |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Inherited via Credential | Minimal: local tokens act after logon |
| T1098.001 | Additional Cloud Credentials | Inherited via Credential | Partial: step-up with OTP on admin actions slows the attacker; added app secrets never see OTP |
The D3FEND site also names Keychain, Steal Web Session Cookie and Steal Application Access Token without IDs; in ATT&CK v20 these are T1555.001, T1539 and T1528. Two techniques aimed at OTP itself are outside D3FEND's D3-OTP list but matter to anyone deploying it: T1111 Multi-Factor Authentication Interception and T1621 Multi-Factor Authentication Request Generation. See the MITRE ATT&CK T1111 Multi-Factor Authentication Interception and the MITRE ATT&CK T1110 Brute Force Guide.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Identity provider | OTP as an allowed second factor with replay rejection and lockout; stronger methods required for privileged roles | SMS left enabled as a fallback for every user |
| VPN and remote access | OTP via RADIUS or the identity provider, failed-attempt limits at the gateway | Gateway-local accounts without OTP |
| Privileged access tools | OTP or stronger at session checkout | Break-glass accounts outside the tool |
| Operating system logon | OTP modules for SSH or console on Linux and Windows hosts where supported | Key-based SSH paths that skip the module |
| Account recovery | Backup codes stored hashed, single use, regenerated after use | Codes downloaded once and kept in a predictable file name |
For SMS and email codes in customer journeys see OTP security and the Magic Links and Email OTP Security Guide.
Where identity fits
OTP assumes a person reads a code. Service accounts and API clients cannot, so they end up in exclusion groups or with OTP seeds stored beside scripts, which turns a one-time factor into a static secret. Use certificate-based or token-based authentication for workloads instead. See the D3-TBA Token-based Authentication card.
Implementation steps
- Inventory where OTP is accepted. List each application and gateway, the OTP types it accepts (SMS, app, token, backup codes) and the fallbacks it allows.
- Check the verifier settings. Confirm replay rejection, a failed-attempt limit, the TOTP acceptance window and the HOTP look-ahead window. Treat any vendor default as something to confirm in its documentation, not assume.
- Restrict SMS and voice. Follow SP 800-63B-4's restricted authenticator rules: offer an app or hardware alternative, tell users the risk and set a date to retire SMS for workforce accounts.
- Fix backup codes. Store them hashed, make each single use, regenerate after use and tell users not to keep them in a predictable file. Clear print spool caches on shared printers, as D3FEND notes.
- Move privileged users to phishing-resistant methods. Keep OTP for users and systems that cannot yet use them. See the Phishing-Resistant MFA Guide.
- Roll out with a fallback. Enforce in rings, keep a monitored break-glass account and a documented way to revert a policy.
How to verify it works
- Replay test: sign in with a valid code, then submit the same code again within its window. It must be rejected (RFC 6238 and SP 800-63B-4).
- Rate limit test: submit wrong codes to a test account and confirm the lockout or delay engages at the configured threshold, across sessions, as RFC 4226 requires.
- Window test: submit a TOTP from several steps in the past and confirm it is refused outside the configured drift allowance.
- Fallback test: confirm a user who has an app or token cannot drop to SMS without policy allowing it.
- Relay exercise: in an authorised phishing exercise, confirm privileged roles cannot complete sign-in with OTP where phishing-resistant strength is required.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| Sign-ins completed with SMS or voice codes | Use of the restricted authenticator | Falling |
| Privileged accounts whose strongest method is OTP | Exposure to real-time relay | Falling to zero |
| Failed OTP attempts per account per day above threshold | Code guessing attempts | Each one reviewed |
| OTP method resets not preceded by a verified sign-in | Recovery abuse | Zero |
| Accounts excluded from OTP, by type | Bypass surface | Falling; each with owner and expiry |
Limits, bypasses and failure patterns
- Real-time relay: in the Twilio breach, SMS phishing led employees to fake sign-in pages whose kit collected one-time codes and relayed them to attackers before they expired. Twilio moved all employees to FIDO2 keys afterwards.
- SIM swap and delivery compromise: SMS codes go to whoever controls the number. See the SIM Swap Fraud Guide.
- Help desk resets: a strong OTP factor is undone by a reset process that accepts a phone call.
- Loose verifiers: wide acceptance windows, no replay check or no rate limit turn a six-digit code into a guessable secret.
- Seed exposure: TOTP seeds are shared secrets held by the server; a seed database leak lets an attacker generate valid codes, so protect seeds like password hashes and re-enrol after a leak.
- Paths that skip the code: legacy protocols, SSH keys and session tokens authenticate without the OTP prompt.
Framework mapping
| Framework | Reference | Relationship to D3-OTP |
|---|---|---|
| NIST SP 800-63B-4 | Single-factor OTP, multi-factor OTP, look-up secrets, restricted authenticators | Authenticator and verifier requirements and the AAL each OTP type can meet |
| NIST SP 800-53 Rev 5 | IA-2(8) Access to Accounts, Replay Resistant | Single-use codes are a replay-resistant mechanism |
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2), IA-5 Authenticator Management | OTP as a second factor and the management of seeds, tokens and backup codes |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| MITRE ATT&CK | M1032 Multi-factor Authentication | Closest mitigation in intent (NHI Mgmt Group mapping; D3FEND links M1032 to D3-MFA) |
The 800-53, CSF and ATT&CK rows are NHI Mgmt Group's mapping by control intent.
Related countermeasures
- Parent: D3-PR Password Rotation, the scheduled form of the same idea.
- Combination: D3-MFA Multi-factor Authentication, where OTP usually serves as the second factor.
- Brute-force signal: D3-ANET Authentication Event Thresholding and D3-AL Account Locking cover the failed-attempt side.
- Phishing resistance: D3-CTS Credential Transmission Scoping covers the property OTP lacks.
Practitioner checklist
- List every application and gateway that accepts OTP and which OTP types and fallbacks each allows.
- Confirm replay rejection, failed-attempt limits and tight TOTP and HOTP windows on every verifier.
- Treat SMS and voice as restricted: offer alternatives, inform users and set a retirement date.
- Store backup codes hashed, single use, and regenerate after use.
- Protect OTP seed stores like password hashes and plan re-enrolment after any leak.
- Require phishing-resistant methods for privileged roles; keep OTP as a bridge for others.
- Keep workloads off OTP and on certificate or token-based authentication.
- Run replay, rate-limit and relay tests at least yearly and after verifier changes.
Standards and references
- MITRE D3FEND: One-time Password (D3-OTP)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- IETF: RFC 4226 HOTP: An HMAC-Based One-Time Password Algorithm
- IETF: RFC 6238 TOTP: Time-Based One-Time Password Algorithm
- IETF: RFC 2289 A One-Time Password System
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Authenticator Apps and OTP Guide · MFA Guide · Phishing-Resistant MFA Guide · MITRE D3FEND Guide