---
url: 'https://www.corbado.com/blog/hong-kong-sfc-otp-ban-passkeys'
title: 'Hong Kong SFC bans OTPs for Crypto in favor of Passkeys'
description: 'Hong Kong''s SFC banned OTP logins for crypto platforms and internet brokers. Learn the July 2027 deadline, passkey options and what VATPs must do now.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-07-17T11:07:42.928Z'
lastModified: '2026-07-17T11:07:42.928Z'
keywords: 'Hong Kong SFC OTP ban, Hong Kong passkeys crypto, SFC phishing-resistant authentication, VATP authentication Hong Kong, Hong Kong crypto OTP ban, internet broker passkeys Hong Kong, SFC circular 26EC35'
category: 'Passkeys Strategy'
---

# Hong Kong SFC bans OTPs for Crypto in favor of Passkeys

## Key Facts

- On **July 9, 2026**, Hong Kong's **Securities and Futures Commission (SFC)** issued
  [Circular 26EC35](https://apps.sfc.hk/edistributionWeb/gateway/EN/circular/doc?refNo=26EC35)
  requiring **internet brokers** and **virtual asset trading platform operators (VATPs)**
  to stop using **one-time passwords (OTPs)** for **client login** and **device binding**.
- Firms must switch to **phishing-resistant authentication** such as **passkeys** or
  **cryptographically bound devices**, with a hard deadline of **July 8, 2027**. **Large
  internet brokers** are expected to move **immediately**.
- **Phishing attacks** accounted for **57%** of security incidents reported to the Hong Kong
  Computer Emergency Response Team Coordination Centre (**HKCERT**) in **2025**, part of a
  [record 15,877 incidents](https://www.hkcert.org/press-centre/hkcert-releases-hong-kong-cybersecurity-outlook-2026-security-incidents-hit-record-high-with-27-annual-increase-ai-related-attacks-and-supply-chain-risks-emerge-as-top-concerns-nearly-30-of-enterprises-lack-dedicated-cybersecurity-personnel),
  up **27%** year over year.
- The circular is not login-only hygiene. Firms must also improve **surveillance**,
  **client notifications** and **incident response**, and senior management can be held
  **accountable for client losses** when controls fail.

## 1. Introduction: Why Hong Kong's SFC banned OTP logins for crypto platforms

Hong Kong has spent years building a licensed virtual-asset market. By mid-2026 the city had
a small but growing list of **SFC-licensed VATPs** alongside traditional **internet
brokers** that serve retail traders through web and mobile channels. Authentication sat at
the center of that growth story in the wrong way: **OTP-based login** remained the default
even as **phishing** and **account takeover** campaigns scaled up.

On **July 9, 2026**, the SFC moved from encouragement to enforcement. In
[Circular 26EC35](https://apps.sfc.hk/edistributionWeb/gateway/EN/circular/doc?refNo=26EC35)
the regulator told **internet brokers** and **VATPs** to **cease using OTPs** for **client
login** and **device binding** and to adopt **phishing-resistant authentication** instead.
**Passkeys** and **bound devices** are named explicitly as acceptable paths.

This post covers four practical questions compliance and product teams are already asking:

1. **Who** must comply and **which** authentication flows are in scope?
2. **Why** did the SFC decide OTP is no longer defensible for login and device binding?
3. **What** should replace OTP, and where do **passkeys** fit?
4. **How** can firms reach the **July 8, 2027** deadline without breaking conversion or
   support operations?

## 2. What Circular 26EC35 requires

The SFC's July 2026 circular is narrow in scope but firm in tone. It does **not** rewrite
Hong Kong's entire cybersecurity rulebook. It targets two high-risk moments in the client
journey:

- **Client login** to internet trading or VATP accounts
- **Device binding**, when a client registers or links a new phone or computer to an account

For those two processes, **OTP must go**. The regulator expects **phishing-resistant
authentication** implemented **as soon as practicable** and **no later than 12 months**
from the circular date, which sets **July 8, 2027** as the outside compliance date.

### 2.1 Who is in scope

The circular addresses:

- **Internet brokers**: SFC-licensed corporations engaged in internet trading for Type 1
  (securities), Type 2 (futures), Type 3 (leveraged FX) and/or Type 9 (asset management)
  activities where funds are distributed through internet-based facilities
- **SFC-licensed virtual asset service providers (VASPs)**: the circular notes that this
  currently means **VATP operators**, as virtual asset trading platforms are the only type
  of virtual asset service under Schedule 3B of Hong Kong's Anti-Money Laundering and
  Counter-Terrorist Financing Ordinance

Retail [banking](https://www.corbado.com/passkeys-for-banking) under the **Hong Kong Monetary Authority (HKMA)** is
a separate perimeter. HKMA has its own e-banking authentication guidance and has been
pushing stronger customer authentication for years, but this July 2026 rule is an **SFC
intermediaries** measure focused on **brokers and crypto platforms**.

### 2.2 What stays unchanged

The ban applies to **login** and **device binding** only. If a platform still uses OTP for
other step-up scenarios outside those two entry points, that use is **not** automatically
covered by this circular. In practice most teams will still review the full authentication
map because any remaining OTP path can become the weakest link attackers pivot to.

Existing device bindings do not need a forced mass re-enrollment on day one. The requirement
bites when clients **log in** or **register a new device** using methods that must become
phishing-resistant by the deadline.

### 2.3 Timeline and expectations for large brokers

| Firm type | Expected timing |
| --- | --- |
| Large internet brokers | Implement phishing-resistant login and device binding **immediately** |
| Other internet brokers and VATPs | **As soon as practicable**, latest **July 8, 2027** |
| Monitoring, notifications and incident response | Strengthen **now**, not after the auth migration finishes |

The SFC had already encouraged firms to stop using SMS OTP in its
[February 2025 cybersecurity review](https://apps.sfc.hk/edistributionWeb/api/circular/list-content/circular/intermediaries/supervision/doc?lang=EN&refNo=25EC7).
The July 2026 notice turns that warning into a dated migration obligation.

## 3. Why OTP failed as the front door for trading accounts

OTP felt reasonable when mobile trading apps were new. Send a six-digit code, verify
possession of a phone, move on. Attackers adapted faster than the UX aged.

### 3.1 Real-time phishing beats delayed codes

Modern [phishing](https://www.corbado.com/glossary/phishing) kits do not just steal passwords. They proxy the
entire login session in real time, so an SMS code, email code or authenticator-app OTP the
victim types on a fake broker page is forwarded to the genuine service within seconds. The
diagram below traces how that relay plays out.

From the platform's perspective the login looks legitimate. That pattern is especially
painful in **crypto** and **leveraged trading**, where stolen
sessions can lead to rapid asset movement. [Binance](https://www.corbado.com/blog/binance-passkeys) and
[Coinbase](https://www.corbado.com/blog/coinbase-passkey) were early passkey adopters partly because account
takeover in crypto has immediate financial impact.

### 3.2 Hong Kong's 2025 incident data

[HKCERT recorded 15,877 cybersecurity incidents in 2025](https://www.hkcert.org/press-centre/hkcert-releases-hong-kong-cybersecurity-outlook-2026-security-incidents-hit-record-high-with-27-annual-increase-ai-related-attacks-and-supply-chain-risks-emerge-as-top-concerns-nearly-30-of-enterprises-lack-dedicated-cybersecurity-personnel),
a **27% jump** year over year. **Phishing** accounted for **8,973 incidents**, or **57%** of
the total, ahead of botnet activity (**18%**) and malware (**15%**). The SFC circular
describes 2025 campaigns in which fraudsters impersonated brokers, regulators or government
bodies through SMS links and relayed credentials and OTPs to conduct unauthorized
transactions.

The risk was already visible before 2025. In November 2024 the
[SFC restricted assets totaling HK$91 million](https://apps.sfc.hk/edistributionWeb/api/news/list-content?lang=EN&refNo=24PR200)
across accounts held at four brokers, including Interactive Brokers Hong Kong, after
suspected market manipulation or fraud involving unauthorized trades through hacked
accounts. The HK$91 million figure refers to assets covered by the restriction notices,
not confirmed client losses.

That is the same regional pattern regulators elsewhere have been closing off. Singapore's
MAS pushed banks away from SMS OTP in 2024. The UAE's CBUAE set a **March 2026** phase-out
for SMS and email OTP in banking. Hong Kong's SFC rule is the **crypto and internet-broker
slice** of that broader Asia-Pacific shift.

### 3.3 Why app-based OTP is still OTP

Teams sometimes ask whether moving from SMS to an authenticator app satisfies the spirit of
the rule. The SFC's language targets **OTP as a class** for login and device binding, not
just delivery over SMS or email. A time-based code the user can type into a fraudulent page
still fails the **phishing-resistance** bar the circular is trying to enforce.

## 4. Compliant alternatives: passkeys, bound devices and hardware keys

The SFC does not prescribe a single vendor stack. It describes outcomes: authentication
that **cannot be replayed** through a fake website or message channel.

### 4.1 Passkeys (FIDO2 / WebAuthn)

**Passkeys** are the most direct replacement for OTP login in consumer-facing apps. They
use **public-key cryptography**. During registration, the authenticator creates a key pair.
The platform stores the public key while the private key stays on the device or in an
OS-backed credential manager. At login, the platform sends a fresh, random challenge. The
authenticator signs it with the private key and binds the response to the platform's
**relying party ID** and origin. The platform then verifies the signed challenge with the
stored public key. A fresh challenge is valid only once, so an intercepted response cannot
be replayed for a later login.

That origin binding is the technical reason passkeys resist phishing, as the diagram below
contrasts: a credential created for `exchange.example` simply will not authenticate on a
look-alike domain like `exchange-secure-login.example`, even if the page looks identical.

For VATPs and brokers, passkeys also align with how major crypto platforms already think
about security. Public-key authentication is native to the asset class. Rolling out
passkeys is less of a conceptual leap for crypto users than for legacy password-only retail
banking cohorts.

Practical rollout notes:

- Support **platform authenticators** on iOS, Android and desktop browsers first
- Offer **[Conditional UI](https://www.corbado.com/blog/user-transition-passkeys-conditional-ui)** on web login
  where client capabilities allow it
- Plan **[passkey recovery](https://www.corbado.com/blog/passkey-fallback-recovery)** before marketing "passwordless
  trading"
- Track **[native app passkeys](https://www.corbado.com/blog/native-app-passkeys)** separately from web; crypto
  users split heavily across mobile apps and browser access

### 4.2 Bound devices with cryptographic verification

The SFC also accepts **device binding** where a client registers a phone or computer using
**securely enrolled device attributes** plus an additional factor such as **biometrics** or
an account password. This resembles the
**[digital token model used by Singapore banks](https://www.corbado.com/blog/singapore-passkeys-banks)** after the
MAS OTP phase-out, though Hong Kong's crypto context adds higher withdrawal velocity and
hotter fraud targets.

The circular does not prescribe a fixed list of device attributes. In practice, secure
enrollment usually means the app creates a device-specific cryptographic key and registers
its public key with the account. The private key remains in hardware-backed storage such as
the iOS Secure Enclave or Android Keystore. The platform can combine that proof with an app
instance or device identifier and integrity signals. A copied device ID alone is not enough:
the device must prove possession of the enrolled private key when it logs in.

Device binding can work well when clients mostly trade from one phone. It gets harder when
users expect seamless multi-device access unless the platform also supports synced passkeys
or a controlled re-binding flow with cooling-off rules.

### 4.3 Hardware security keys

[FIDO2 hardware security keys](https://www.corbado.com/blog/best-fido2-hardware-security-keys) can hold passkeys
and provide a phishing-resistant option, especially for high-value accounts, institutional
sub-accounts or staff access. The circular explicitly names **passkeys** and **bound
devices** as examples but does not prescribe one authenticator form factor.

### 4.4 Credential limits and session controls

The circular carries forward two controls that are easy to miss in a passkey migration:

- Firms generally should not allow more than **three passkeys and/or three bound devices**
  per trading account. Requests above that limit require an adequate assessment.
- Clients must not be able to disable session timeout. The SFC gives **30 minutes** as an
  example maximum idle period unless a longer session is justified, assessed and closely
  monitored.

These requirements matter for shared corporate accounts. Instead of binding many devices
to one credential set, firms should consider individual sub-accounts and controls over
concurrent logins.

## 5. Detection and response: the other half of the circular

Authentication migration is only the **prevention** layer. Circular 26EC35 also expects
**monitoring**, **client communication** and **incident response** improvements in parallel.

Firms should be able to:

- Detect **irregular logins**, **new-device activity**, unusual **trading patterns** and
  suspicious **withdrawals**
- **Notify clients promptly** of successful logins and higher-risk account changes,
  including **passkey creation or revocation**, through multiple channels where applicable
- **Restrict or suspend** accounts when fraud indicators appear
- **Respond quickly** to hacking incidents and keep clients informed about emerging
  impersonation scams

The SFC also lists concrete monitoring signals: transactions at unusual hours, rapid losses,
large volumes in illiquid or small-cap stocks, activity shortly after a password reset or
new device binding, bindings from unusual locations, multiple accounts bound to one device,
logins from multiple locations within a short period and unusually long sessions. Firms
must retain enough device and login data to investigate these patterns.

SMS is not banned as a notification channel. The circular allows email, SMS and push
notifications for account alerts. The restriction concerns using OTP as an authentication
factor for **login** and **device binding**.

Dr Eric Yip, the SFC's Executive Director of Intermediaries, framed the requirement as
needing **"holistic measures combining prevention, detection, response and education."** He
added that licensed firms should strengthen their first line of defence with robust
authentication, stay alert to suspicious activities and respond before harm is done.
Product teams should read that as a signal that a passkey launch without telemetry upgrades
will not satisfy supervisors.

## 6. Implementation roadmap to July 8, 2027

Twelve months is enough time only if work starts immediately. A realistic plan for VATPs and
internet brokers looks like this:

### 6.1 Phase 1: Auth inventory and architecture (Q3 2026)

- Map every **login**, **device-binding** and **recovery** path that still uses OTP
- Decide the **primary** consumer method (usually passkeys) and **fallback** policy for
  unsupported devices
- Align **Web** and **native app** ceremonies so clients are not pushed back to OTP on one
  surface only
- Review **third-party identity**, white-label apps and API-only clients that share the
  same account directory

### 6.2 Phase 2: Build, pilot and measure (Q4 2026 - Q1 2027)

- Implement **WebAuthn registration and assertion** flows with explicit RP ID and
  [related origins](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) coverage for
  marketing domains
- Run pilots on **new registrations** first, then **returning users** with
  [passkey append](https://www.corbado.com/blog/passkey-creation-best-practices) prompts after successful password
  login
- Instrument **creation rate**, **login success**, **error codes** and **fallback rate** by
  OS and browser before full cutover
- Update **support playbooks** for lost devices, sync issues and cross-platform passkey
  mismatches
- Test the new authentication methods adequately before deployment, then roll them out to
  **all clients** as soon as practicable with clear implementation guidance

### 6.3 Phase 3: OTP cutover and compliance evidence (Q2 - July 2027)

- Disable OTP for **login** and **new device binding** on the deadline path
- Notify the firm's **SFC case officer immediately** if meeting the 12-month implementation
  period becomes difficult; the circular does not establish a general legacy-client
  exception
- Produce **audit evidence**: auth policy changes, penetration test results, monitoring
  rule updates and customer notification logs

Large internet brokers should compress this timeline dramatically and treat **immediate**
adoption as the operational baseline, not a stretch goal.

## 7. Liability, governance and what senior management should expect

The SFC did not frame Circular 26EC35 as optional best practice. The press statement
reminds **senior management** that they are **"ultimately responsible for implementing
appropriate controls to protect client accounts and assets"** and that the regulator
**"will hold them accountable for any client losses that arise from lapses in their
controls."**

The circular assigns particular responsibility to the **Manager-in-Charge of Overall
Management and Oversight** and the **Manager-in-Charge of Information Technology**. It also
requires hacking incidents to be reported to the SFC immediately, followed by root cause
analysis, a detailed incident report and remedial action.

That wording changes the internal business case. A delayed passkey rollout is not just a
product backlog item. It is a **control deficiency** with potential **client-loss
exposure** if phishing incidents continue through the migration window.

Governance teams should treat the program as a joint **technology**, **risk** and
**customer-education** workstream, with board-visible metrics on:

- Share of logins still using OTP
- Passkey adoption and successful assertion rate by platform
- Mean time to detect and suspend suspicious withdrawals after credential compromise
- Volume and outcome of impersonation-scam client notifications

## 8. Regional context: Hong Kong joins the OTP exit lane

Hong Kong's move fits a wider **Asia-Pacific** pattern documented across Corbado's
compliance coverage:

- **[Singapore (2024)](https://www.corbado.com/blog/singapore-passkeys-banks)**: MAS and ABS pushed retail banks
  from SMS OTP toward cryptographic digital tokens
- **[Malaysia (2025)](https://www.corbado.com/blog/malaysia-banking-mfa-passkeys)**: BNM's updated RMiT framework
  expects phishing-resistant MFA and device-bound credentials
- **[UAE (March 2026)](https://www.corbado.com/blog/uae-banking-otp-phase-out)**: CBUAE ends SMS and email OTP for
  banking authentication
- **[Brazil (March 2026)](https://www.corbado.com/blog/brazil-cybersecurity-regulation)**: CMN and BCB resolutions
  mandate auditable MFA for financial infrastructure

Hong Kong's version is distinctive because it lands first on **licensed crypto trading
platforms** and **internet brokers** under the SFC, at a moment when spoofing dominated
local incident statistics. It is also one of the clearest regulator statements that
**passkeys belong in the compliance conversation**, not only in developer blogs.

## 9. How Corbado can help

Circular 26EC35 creates a dated migration with real liability attached. VATPs and brokers
need to **replace OTP on login and device binding**, keep unsupported devices from breaking
and prove to supervisors that the new flows actually work in production.

Corbado **Connect** helps teams ship [passkey-first login](https://www.corbado.com/blog/passkey-login-best-practices)
on top of an existing identity stack without migrating user databases. For crypto platforms
that still run password-plus-OTP today, that means adding **append flows**, **fallback
routing** and **gradual rollout** controls while OTP is phased out on the two regulated
surfaces.

What teams typically use during an SFC-style migration:

- **Activation analytics** to see where passkey enrollment stalls after sign-in
- **Login funnel telemetry** to compare completion rates against legacy OTP paths by OS and
  browser
- **Error clustering** for WebAuthn failures so support is not guessing from ticket volume
  alone
- **Gradual rollout rules** to suppress broken environments while adoption ramps

[Watch video](https://www.corbado.com/videos/features/enrollment.mp4)

## 10. Conclusion

Hong Kong's SFC did not ban every OTP in financial services. It banned OTP where phishing
does the most damage: **client login** and **device binding** for **internet brokers** and
**VATPs**. The approved direction is **phishing-resistant authentication**, with **passkeys**
and **bound devices** named as practical examples.

The operational deadline is **July 8, 2027**, with **large internet brokers** expected to
move now. The harder part is not selecting passkeys on a slide deck. It is migrating a live
trading population, keeping fraud monitoring current and showing supervisors that the new
controls actually reduced account takeover risk.

For crypto platforms that already market security as a brand promise, the circular is both
a compliance task and a chance to align product UX with the cryptography their users
already understand.

## Frequently Asked Questions

### Did Hong Kong ban SMS and email OTP for all financial services?

No. The July 9, 2026 SFC circular targets internet brokers and licensed virtual asset
trading platform operators. It prohibits one-time passwords for client login and device
binding only. Other OTP use cases outside those two flows are not covered by this specific
ban.

### When must Hong Kong crypto platforms stop using OTP logins?

Licensed internet brokers and VATPs must implement phishing-resistant authentication for
client login and device binding as soon as practicable and no later than 12 months from the
circular date, which sets a compliance deadline of July 8, 2027. Large internet brokers are
expected to adopt the new methods immediately.

### Are passkeys compliant with the Hong Kong SFC OTP ban?

Yes. The SFC explicitly names passkeys as an example of a phishing-resistant authentication
method alongside bound devices. Passkeys based on FIDO2/WebAuthn use public-key cryptography
tied to the legitimate service origin, which addresses the real-time OTP relay attacks that
motivated the circular.

### Can Hong Kong VATPs still use authenticator-app TOTP instead of passkeys?

The SFC states that OTP is not a phishing-resistant authentication solution and should not
be used for client login or device binding. App-based TOTP still relies on a shared secret
that users can be tricked into entering on a fake site, so it does not satisfy the spirit
of the circular even if delivery is not via SMS or email.

### What happens if a Hong Kong broker fails the SFC authentication deadline?

The SFC reminds senior management that they are ultimately responsible for controls that
protect client accounts and assets. The regulator said it will hold firms accountable for
client losses arising from control lapses, which raises the operational and financial stakes
beyond a simple technical migration.

### How does the Hong Kong SFC OTP ban relate to HKMA banking rules?

They are separate regimes. The July 2026 SFC circular covers securities and virtual-asset
intermediaries under SFC supervision. HKMA e-banking guidance applies to authorized
institutions such as banks, so firms must assess the rules that apply to their own
regulatory perimeter.