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

At a glance

What this is: Hong Kong’s SFC is phasing out OTP for client login and device binding because code-based authentication cannot stop proxy phishing and real-time relay attacks.

Why it matters: IAM teams in regulated sectors need to treat login, device binding, and recovery as one control chain, because a weak fallback can undermine an otherwise strong authentication programme.

By the numbers:

• Phishing accounted for 57% of the total.
• The SFC issued circular 26EC35 on 9 July 2026 and set an 8 July 2027 deadline for OTP removal.

👉 Read Authsignal's analysis of Hong Kong's SFC OTP ban and passkey migration

Context

OTP login is still common in regulated financial services because it is easy to deploy, familiar to users, and cheap to operate. The problem is that OTP proves code possession, not session legitimacy, so a phished code can still be replayed through a lookalike site or a man-in-the-middle proxy. In Hong Kong, that gap now matters directly to broker and virtual asset platform identity controls.

The Securities and Futures Commission has made the issue explicit by extending the control requirement to login and device binding, not just sensitive transactions. For identity and access teams, that means the authentication architecture must be judged as a lifecycle problem: enrolment, login, new-device binding, recovery, notifications, and monitoring all have to work together or the whole model stays exposed.

Key questions

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. Passkeys, bound devices, and strong identity verification should be the default, while SMS fallback should be removed from paths that can create a trusted device or restore account access. If recovery stays weak, the migration is incomplete.

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. A phisher can capture the code on a fake page and relay it to the real platform before it expires. That makes OTP vulnerable to proxy attacks even when delivery and expiry settings look reasonable.

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. Once that happens, later biometric checks or step-up prompts may succeed on attacker-controlled hardware. The compromise persists because the trust anchor has already moved.

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.

Technical breakdown

Why OTP fails against proxy phishing

OTP is a shared-secret pattern with a very short usability window. Even when a code expires quickly, it can still be captured and relayed in real time to the legitimate site, which is why man-in-the-middle phishing defeats the factor without needing SIM swap or SS7 compromise. In practical terms, the attacker does not need to crack the code, only to move faster than the human user and sit between the user and the platform. That makes OTP weak against lookalike sites, device-bound session replay, and AI-assisted phishing at scale.

Practical implication: replace OTP with phishing-resistant authentication where the credential is cryptographically bound to the real domain.

How passkeys and bound devices change the trust model

Passkeys use public-key cryptography so the private key stays on the user device, while the platform verifies a signature using the public key. Because the signature is scoped to the legitimate origin, a fake site cannot obtain a reusable assertion. Bound-device approaches work differently but aim at the same outcome: the device itself becomes part of the trust boundary rather than a code sent out-of-band. That shifts identity from something the user types to something the platform can verify against a known device or key.

Practical implication: ensure your login design uses origin-bound credentials or device binding rather than reusable one-time codes.

Why recovery is the weak point after OTP removal

The hardest part of removing OTP is not the primary login flow, but account recovery and first-time device binding. If recovery still falls back to SMS or weak identity proofing, the attacker simply targets the weakest path and bypasses the stronger one. That is why the control model has to cover creation, revocation, replacement, and recovery with equal strength. In regulated environments, recovery is not an exception path. It is part of the authentication system and must be governed as such.

Practical implication: redesign recovery and device re-enrolment so they are no weaker than your strongest login method.

Threat narrative

Attacker objective: The attacker wants to turn a single phished login into durable account control that can survive later biometric checks and enable fraudulent transactions.

1. Entry occurs when a client receives a convincing SMS phishing message that links to a fake broker or regulator page and enters credentials plus OTP.
2. Escalation occurs when the attacker relays the captured code in real time to the real platform and uses the session to bind a new trusted device.
3. Impact occurs when the attacker can persist through the newly bound device and initiate unauthorised transactions or account changes while appearing legitimate.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Device binding is where weak fallback design becomes a durable compromise. If an attacker can phish the first binding event, later biometric checks or app-based approvals can authenticate the attacker’s hardware just as readily as the customer’s. That is a lifecycle failure, not a login failure, because the wrong device becomes the trusted device. Practitioners should treat binding, recovery, and revocation as the same control plane.

Phishing-resistant authentication is now a governance requirement, not a product feature. Passkeys matter here because they bind the credential to the legitimate domain and remove the replay problem that OTP cannot solve. The named concept is replay-safe enrollment gap: if recovery or new-device enrollment still relies on reusable codes, the migration leaves the real weakness untouched. The practical conclusion is that migration plans must include the entire enrollment chain.

Accountability has moved upstream into access design. The SFC’s warning that firms may be held accountable for losses caused by hacked client accounts means control failure now sits with the identity programme, not only with fraud monitoring. That changes how brokers should think about access assurance, session integrity, and lifecycle controls across login and device trust. The practical conclusion is that identity governance is part of loss prevention, not a separate compliance exercise.

From our research:

• 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.
• For a broader identity lens, see Ultimate Guide to NHIs , The NHI Market for how identity controls map to emerging access patterns.

What this signals

The migration away from OTP is part of a wider shift toward phishing-resistant identity controls across regulated access journeys. For brokers and platforms, the practical question is no longer whether SMS can deliver a code, but whether the entire binding and recovery chain can withstand adversary-in-the-middle abuse. For that reason, teams should review their authentication architecture alongside NIST SP 800-63 Digital Identity Guidelines and the design assumptions behind step-up and recovery flows.

Replay-safe enrollment gap: this is the point where organisations think they have solved login risk but leave recovery, device replacement, or binding as the exploitable path. If the fallback can still be phished, the control remains cosmetic. Teams should map every place a client can create or restore trust and remove any path that does not require origin-bound proof, auditable identity verification, and strong session correlation.

The programme-level signal is that identity and fraud can no longer be separated cleanly in regulated consumer access. The strongest controls now combine access assurance with event correlation, because an account takeover often looks like a normal login until the downstream transaction arrives. Aligning monitoring with the control intent of NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams connect authentication, audit, and anomalous behaviour detection.

For practitioners

• 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. Prioritise regulated customer journeys where login is the first point of compromise, not only high-risk transactions.
• Rebuild device binding as a governed lifecycle event Require strong identity verification for new-device binding, device replacement, and device revocation. Treat these steps as part of the trust chain, not support tasks, and log every binding event for audit and dispute handling.
• 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. If a customer loses a phone or hardware key, recovery should still prove identity without recreating the original phishing gap.
• Correlate login, binding, and trading signals Alert on sequences such as password reset, new device binding, unusual location, and immediate trading activity. The SFC’s examples show that a single authentication event is less useful than the event chain around it, especially when fraud unfolds quickly.
• Assign explicit senior ownership for rollout Make the Manager-in-Charge of IT and the Manager-in-Charge of Overall Management accountable for authentication migration milestones, exception handling, and client-loss reporting. That keeps the programme from becoming a deferred compliance project.

Key takeaways

• OTP is too weak for environments where real-time relay phishing can replay a code before it expires.
• The real governance risk sits in device binding and recovery, because that is where an attacker can turn one phished login into persistent control.
• Brokers and crypto platforms should treat phishing-resistant authentication, lifecycle-bound device trust, and event correlation as one programme, not separate controls.

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.
• Replay Attack: An attack where a previously valid signed message is captured and sent again later to trigger the same trusted action. Timestamping, nonces, and context binding are the main controls that reduce replay risk in HMAC-based systems.
• 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.

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

👉 Authsignal's full post covers the SFC requirements, binding rules, recovery paths, and implementation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.