How should security teams handle HOTP secret re-creation so user presence and user verification are both enforced?

Security teams should treat HOTP secret re-creation as a high-risk action and require two independent checks: user verification through a PIN and user presence through a physical touch. That combination reduces the chance of silent re-enrolment or misuse of a recovered device. Update both the firmware and the surrounding access workflow so the control is enforced consistently.

Why This Matters for Security Teams

HOTP secret re-creation is not a routine reset. It is a privileged identity recovery event that can silently re-enrol a device, restore access on a recovered token, or overwrite a valid binding if the workflow only checks one factor. When the goal is to enforce both user presence and user verification, the control has to be applied at the firmware layer and in the surrounding identity workflow, not treated as a help desk convenience. Current guidance on OWASP Non-Human Identity Top 10 emphasizes that credentials and authenticators need lifecycle controls, because once a secret is recreated the blast radius is the same as a fresh compromise if the process is weak.

This matters because recovery paths are where mature programs often drift into exception handling. The wrong assumption is that a user can simply prove possession of the device and the risk is contained. In reality, possession alone does not distinguish an intentional reset from a coerced or automated one. NHIMG’s Ultimate Guide to NHIs shows how often weak lifecycle controls leave long-lived secrets exposed, and the same pattern applies when authenticators are re-created without strong approval gates. In practice, many security teams discover the weakness only after a recovered token is re-enrolled and the original trust boundary has already been bypassed.

How It Works in Practice

The secure pattern is to require two independent checks before an HOTP secret can be recreated: user verification and user presence. User verification means the person must prove knowledge of a PIN or equivalent local secret. User presence means the action must be physically confirmed on the authenticator, such as a touch or button press. Those checks should be enforced by the device or firmware, not only by the application, so that the re-creation event cannot be bypassed by a weaker upstream workflow.

Practically, the flow should look like this:

• The help desk or enrollment portal initiates a bounded re-creation request.
• The authenticator requires a valid PIN to satisfy user verification.
• The authenticator then requires a physical touch to satisfy user presence.
• The new HOTP secret is generated or activated only after both checks succeed.
• The old secret is invalidated immediately and the event is logged for review.

That design aligns with broader identity guidance from NIST SP 800-63B, which distinguishes between verifier-controlled activation and local user verification for authenticators. It also maps to the operational reality described in NHIMG’s Guide to the Secret Sprawl Challenge, where weak lifecycle controls allow secrets to persist longer than intended. The surrounding workflow should enforce step-up approval, rate limits, and audit trails so the reset cannot be repeated at speed. These controls tend to break down in remote support environments where technicians can override device prompts or where legacy firmware cannot bind PIN and touch to the same re-creation transaction.

Common Variations and Edge Cases

Tighter recovery controls often increase support friction, requiring organisations to balance account recovery speed against the risk of silent re-enrolment. That tradeoff is real, especially in fleets that include older hardware, kiosk devices, or mixed authenticator models.

Best practice is evolving on whether the PIN should be validated entirely on-device or by a trusted companion workflow, but there is no universal standard for this yet. The safer approach is to avoid any design where the PIN can be checked separately from the touch event or where either check can be replayed across sessions. If the authenticator cannot enforce both conditions locally, the policy should fail closed rather than downgrade the requirement.

Implementation teams should also watch for edge cases such as lost devices, device migration, and help desk escalations for high-value users. Those cases need stronger identity proofing, break-glass review, and immediate revocation of the old secret. For broader context on how secret lifecycle failures create downstream exposure, see NHIMG’s 52 NHI Breaches Analysis and the Gladinet Hard-Coded Keys RCE Exploitation case study, which both show how quickly exposed credentials become an operational incident when renewal and revocation are weak.

Related resources from NHI Mgmt Group

• How do security teams measure whether secret scanning is actually reducing exposure?
• How should security teams handle guest user access in SaaS platforms?
• How should security teams handle secret rotation after a breach or exposure?
• How should security teams handle secret rotation for non-human identities?