Notifications
Clear all
Topic starter
11/08/2026 3:16 pm
TL;DR: Hong Kong’s Securities and Futures Commission now requires brokers and virtual asset platforms to stop using OTPs for client login and device binding, citing large-scale phishing and real-time relay attacks that bypass code delivery, according to Authsignal. The shift makes phishing-resistant authentication and recovery design the real control surface for IAM teams.
NHIMG editorial — based on content published by Authsignal: Hong Kong's SFC has told brokers and crypto platforms to drop OTP login
By the numbers:
- Phishing accounted for 57% of the total.
Questions worth separating out
Q: How should broker platforms replace OTP without breaking client access?
A: Start with login, then extend the same control model to device binding and recovery.
Q: Why do OTP-based login flows fail in regulated financial services?
A: Because OTP proves a code was received, not that the user reached the legitimate site.
Q: What breaks when device binding relies on SMS OTP?
A: The attacker can register their own phone or app as a trusted device after intercepting the binding code.
Practitioner guidance
- Replace OTP with phishing-resistant login factors Use passkeys or equivalent origin-bound credentials for client login so the authentication factor cannot be replayed through a fake site or proxy.
- Rebuild device binding as a governed lifecycle event Require strong identity verification for new-device binding, device replacement, and device revocation.
- Eliminate weak recovery fallbacks Remove SMS OTP from recovery paths and replace it with methods that are at least as strong as the primary login control.
What's in the full article
Authsignal's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step passkey and bound-device migration guidance for login, binding, and recovery
- The SFC circular's implementation nuances for brokers, virtual asset platforms, and senior management accountability
- Practical monitoring examples for password-reset, new-device, and trading-sequence correlation
- Operational handling for clients who cannot yet move to passkeys or hardware-backed credentials
👉 Read Authsignal's analysis of Hong Kong's SFC OTP ban and passkey migration →
OTP login bans in Hong Kong: are broker controls keeping up?
Explore further
11/08/2026 3:29 pm
OTP removal is not an authentication tweak. It is a reset of the identity trust model. The SFC is effectively saying that a code sent to a phone is no longer a sufficient proof of login legitimacy when proxy phishing can relay it in real time. For IAM teams, the lesson is that authentication must be evaluated against attacker mediation, not just factor diversity. The practical conclusion is that code-based trust no longer belongs at the front door of regulated access.
A few things that frame the scale:
- HKCERT logged 15,877 cybersecurity incidents in 2025, a record for Hong Kong and a 27% increase year on year, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when weak authentication recovery is exploited?
A: Accountability sits with the identity governance and security teams that own the full authentication journey, including reset and recovery paths. A strong primary factor does not compensate for a weak recovery process. The control boundary must include verification, logging, and escalation before privileged access is restored.
👉 Read our full editorial: Hong Kong SFC’s OTP ban shifts login risk to phishing-resistant auth
