Hong Kong SFC’s OTP ban shifts login risk to phishing-resistant auth

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Authsignal's blog post: Hong Kong's SFC has ordered brokers and virtual asset platforms to remove OTPs from client login and device binding because phishing and real-time relay attacks can bypass code-based authentication.

Why it matters: IAM teams running customer-facing access in regulated environments need to treat login, device binding, and recovery as one authentication chain, because a weak fallback can undo stronger primary controls.

By the numbers:

• Phishing accounted for 57% of the total incidents HKCERT logged in 2025.

Context

OTP-based login has become a poor fit for broker and trading-platform access because the code can be captured, relayed, and replayed in real time. In customer identity programmes, the failure is not only the factor itself but the assumption that the code proves the client is on the legitimate site.

Hong Kong’s SFC circular makes that problem explicit by applying the change to both login and device binding, not just to transfers or step-up checks. That matters for IAM because a secure-looking primary login can still be undermined if device registration and recovery remain SMS-dependent.

The article’s central point is that authentication design has to be evaluated as a full lifecycle, including enrolment, binding, notification, and recovery. If any one of those flows still accepts an OTP as a trust anchor, the overall control chain remains replayable.

Key questions

Q: What breaks when OTP authentication can be replayed or reused during a phishing attack?

A: When an OTP can be replayed, a phisher can capture a legitimate authentication attempt and reuse it before the token expires. That undermines the value of the second factor and can let attackers mirror real user activity. Strong implementations limit token lifetime, reject already seen codes, and create auditable events when reuse is attempted so the user must authenticate again.

Q: Why do OTP-based device binding flows create account takeover risk?

A: Device binding becomes risky when the first trusted device is registered with a phishable factor, because the attacker can install their own hardware as the trusted endpoint. After that, later biometrics or app prompts may appear strong while still running on attacker-controlled hardware. The binding step is what needs the strongest verification.

Q: How should brokers design recovery when passkeys replace SMS OTP?

A: Recovery should be treated as a separate high-assurance identity path, not a convenience fallback. If the only way back into the account is an SMS code or a lightly verified helpdesk reset, the weakest path becomes the one attackers target. Strong recovery needs verified identity proofing and controlled device re-enrolment.

Q: Who should own authentication risk when regulators ban OTP login?

A: Ownership should sit with senior management, security, and IT together, because authentication is now a regulated control chain that affects client losses directly. The practical question is not who administers the product, but who is accountable for login, binding, recovery, and monitoring working as one governed process.

Technical breakdown

Why OTPs fail against real-time relay phishing

One-time passwords were designed to prove possession of a second factor, but they do not prove where the code is entered. In a real-time relay attack, the attacker places a fake broker site between the client and the real platform, captures the credential and OTP, then forwards them immediately to the legitimate login page. Because the OTP is valid for the real site as well, the platform cannot distinguish the victim from the proxy in time. Shorter code lifetimes and better SMS delivery do not change that trust problem.

Practical implication: stop treating OTP delivery as a sufficient login control for phishing-prone customer journeys.

Device binding can turn a weak factor into durable account control

Device binding is often the point where a temporary compromise becomes persistent access. If an attacker captures an SMS OTP during device registration, they can register their own phone as a trusted device and keep using it for later logins or approvals. That means the security of later biometrics or app-based prompts depends on the integrity of the original binding step. The circular’s focus on new devices and recovery is important because that is where attackers can establish long-lived trust without ever defeating the stronger factor directly.

Practical implication: treat device enrolment and replacement as privileged identity events, not routine UX steps.

Passkeys shift trust from shared codes to domain-bound cryptography

Passkeys work differently because the private key stays on the client device or in a passkey manager, while the broker stores only the public key. The signed assertion is bound to the legitimate domain, so a lookalike phishing site cannot reuse it the way it can replay an OTP. That changes the attack surface from code interception to credential lifecycle, recovery, and device trust. The article also notes certification, strong identity verification for registration, and controls for synced passkeys, which shows that phishing resistance is only durable when recovery is equally strong.

Practical implication: pair passkey adoption with recovery controls that cannot be bypassed through SMS fallback.

Threat narrative

Attacker objective: The attacker’s objective is to take over client accounts and use them for unauthorised transactions without needing SIM swap infrastructure or code interception at the telecom layer.

1. Entry occurs through large-scale phishing messages that direct clients to a fake broker or regulator-branded site.
2. Credential access follows when the client enters the password and the OTP into the attacker-controlled page.
3. Impact occurs when the attacker relays the code in real time, binds a device, or reaches the live account through the legitimate login flow.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OTP login is no longer a durable trust mechanism for regulated customer access: The SFC’s intervention shows that code delivery has outlived its security value in phishing-heavy environments. Once an attacker can proxy a session in real time, the OTP proves only that a code was received, not that the legitimate client reached the legitimate site. For IAM teams, the control question has moved from delivery reliability to phishing resistance at the point of authentication.

Device binding has become the hidden persistence layer in customer identity programmes: Many organisations secure the login screen while leaving registration and recovery paths exposed to weaker factors. That creates a durable attacker foothold because the hostile device becomes the trusted device. The governance failure is not just weak MFA, but allowing initial trust establishment to be weaker than the session it is supposed to protect.

Recovery is the real control surface once OTP is removed: The article makes clear that a platform can replace SMS OTP at login and still fail if account recovery remains easy to phish. This is a lifecycle problem, not a point-in-time authentication problem. Practitioners should read the circular as an instruction to govern enrolment, replacement, and fallback as tightly as primary authentication.

Passkeys expose the gap between phishing resistance and migration readiness: The domain-bound cryptography is the easy part; the hard part is rebuilding recovery, synced-device controls, and client support so the new control does not inherit the old fallback weakness. That is where many identity programmes stall. The practical lesson is that phishing-resistant authentication only reduces risk when the surrounding lifecycle is designed to prevent code-based re-entry.

Accountability is moving upward from security engineering into regulated governance: The circular names senior management responsibility and explicitly ties control failure to client losses. That is a broader market signal that customer authentication is no longer a narrow IAM implementation detail. Security, product, and compliance teams now have to treat authentication design as a governance obligation with direct loss accountability.

What this signals

Authentication lifecycle governance now matters more than factor choice: The SFC move shows that the weakest point is often not the primary login method but the fallback paths around enrolment, replacement, and recovery. Teams that migrate to passkeys without redesigning those paths will simply move attacker attention downstream.

Phishing-resistant authentication should be measured as a chain, not a feature: A platform can claim stronger login and still be exposed if a new-device flow, call-centre reset, or synced passkey path can be abused. The practical programme question is whether every route to trust establishment is equally hard to phish.

For practitioners

• Replace OTPs in login flows Remove one-time passwords from customer login paths in regulated access journeys and move to phishing-resistant methods that bind authentication to the legitimate domain.
• Rebuild device binding around stronger verification Require an existing passkey, a live identity check, or an equivalent strong method before a new device becomes trusted, and treat device replacement as a high-risk event.
• Eliminate SMS fallback from recovery Audit every recovery route, including lost-device flows and customer-service reset paths, so an attacker cannot pivot from passkey adoption back to OTP-based trust.
• Correlate authentication and trading events Alert on password resets, new device bindings, unusual logins, and anomalous trading sequences as a single account-risk pattern rather than separate signals.
• Assign named ownership for authentication change Make senior management responsible for the full login, device-binding, and recovery lifecycle so compliance gaps are owned before client losses occur.

Key takeaways

• OTP is no longer a reliable security boundary for regulated customer login when phishing kits can relay codes in real time.
• The SFC’s focus on device binding and recovery shows that attackers target trust creation, not only the login screen.
• Phishing-resistant authentication only holds if recovery, device enrolment, and fallback paths are governed at the same strength as primary login.

Key terms

• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.
• Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.

Deepen your knowledge

NHI governance, human identity, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.