On 9 July 2026, the Securities and Futures Commission issued circular 26EC35. It goes further than most earlier authentication mandates in the region: internet brokers and virtual asset trading platforms licensed in Hong Kong must stop using one-time passwords for client login and device binding. The requirement does not apply only to high-value transfers or high-risk transactions. It starts with login itself.
The deadline is 8 July 2027, although large internet brokers are expected to move sooner. The SFC also warned that if a firm fails to prevent, detect or stop large-scale unauthorised transactions through hacked client accounts, it will hold the firm accountable for client losses.
What prompted the circular
The circular responds to a specific pattern of attacks. Throughout 2025, fraudsters ran large-scale SMS phishing campaigns against clients of Hong Kong brokers and virtual asset platforms. The messages linked to sites impersonating the broker, sometimes under the guise of a request from a regulator or government body. Clients entered their credentials and then entered the OTP sent by the real platform.
HKCERT logged 15,877 cybersecurity incidents in 2025, a record for Hong Kong and a 27% increase year on year. Phishing accounted for 57% of the total.
The SFC suspects that fraudsters used a man-in-the-middle attack. A client received a genuine code from the broker but entered it on a fake site. The attacker then relayed the credentials and code to the real login page in real time. The attack did not require a SIM swap or an SS7 exploit. Because an OTP has no way to tell where it is being entered, it cannot stop a proxy sitting between the client and the platform.
Generative AI has also made convincing phishing messages and fake pages cheaper to produce at scale. Improving SMS delivery or shortening the lifetime of a code does not address that problem.
Login is only half the job
The circular covers two processes: client login and device binding.
Device binding is an easy place to weaken an otherwise sound authentication setup. A broker may add biometric login to its mobile app but continue to bind new devices with an SMS OTP. If an attacker phishes that code, they can register their own phone as a trusted device. Every later biometric check will work as designed, but it will run on hardware controlled by the attacker.
The SFC identifies passkeys and bound devices as acceptable approaches. Firms do not have to make existing clients rebind devices that are already bound, so the immediate work centres on new logins, new devices and recovery rather than forced re-enrolment of the entire client base.
What the SFC expects from passkeys
Passkeys use public-key cryptography. The private key stays on the client’s device, hardware key or passkey manager. The firm stores the public key, which can verify a signature but cannot be used to create one. Because the signature is scoped to the legitimate domain, a passkey registered with a broker will not produce a valid assertion for a lookalike site.
The appendix sets out several implementation requirements:
- Passkey solutions should have appropriate certification. The appendix specifically names FIDO certification for both in-house and third-party solutions.
- Registration must be protected by strong identity verification. An additional passkey for the same account should be created only after the client authenticates with an existing passkey or completes an equally strong check.
- Firms need policies for revocation and recovery when a device, hardware key or passkey manager is lost, compromised, replaced or inaccessible. The client’s identity must be verified before a credential is created, revoked or recovered.
- Synced software passkeys, including those shared through an Apple, Google or Microsoft account, need controls to prevent synchronisation from being abused for unauthorised access.
Recovery deserves as much attention as login. A firm can move most clients to passkeys and still leave SMS OTP in place for people who lose their phones. In that setup, an attacker can simply target the fallback. Removing SMS OTP therefore starts with enrolment and recovery, not only the primary login screen.
The circular also repeats an existing limit: a client should generally bind no more than three passkeys and three devices. Anything beyond that needs an assessment before approval. Firms remain subject to the session-timeout guidance issued in 2020, with idle sessions limited to around 30 minutes unless a longer period is justified and monitored.
Binding and replacing devices
The appendix gives four examples of acceptable ways to bind a new device after the implementation period:
- Authenticate with an existing passkey.
- Match a live selfie against facial data captured with liveness detection during account opening.
- Verify a photo ID using OCR and compare a selfie with the onboarding record.
- Verify the client in person at the firm’s office.
The recovery process begins by de-registering the lost device. A client can do that through a customer-service hotline with identity verification or through a self-service portal accessed from another bound device. The replacement is then bound using one of the approved methods.
Adding another device is relatively simple when the client still has a trusted credential. The harder case is binding the first device or replacing the only credential after a phone is lost. For many retail platforms, that is likely to mean a liveness-checked face match against the onboarding record. It also leaves an auditable record if the client later disputes a transaction.
The measures that apply now
The 12-month implementation period applies to the authentication requirements. The other measures in 26EC35 apply immediately.
Firms are expected to notify clients promptly after a successful login, a login from a new device, a new device binding, or the creation or revocation of a passkey. The SFC also encourages firms to ask clients for confirmation before allowing further transactions after certain material account changes or unusual activity.
Monitoring needs predefined thresholds and red flags based on each client’s profile, trading behaviour, account activity, devices and login patterns. The circular gives concrete examples:
- Trading that is inconsistent with the client’s history.
- Orders placed at unusual hours.
- Transactions that cause significant losses in a short period.
- Sudden large volumes in illiquid or small-cap stocks.
- Transactions soon after a password reset, contact-detail change or new device binding.
The SFC also identifies suspicious authentication activity, including device-binding requests from unusual locations, one device bound to multiple client accounts, logins from several locations within a short period and unusually long sessions. Detecting a password-reset-then-trade sequence requires firms to correlate authentication and trading events.
Firms must report hacking incidents to the SFC immediately, together with their root-cause analysis and remedial action. The circular connects this requirement to existing obligations under the Code of Conduct and the VATP Guidelines. Firms cannot treat an incident as an internal matter to resolve before notifying the regulator.
Responsibility also sits with named members of senior management. The Manager-in-Charge of Overall Management and Oversight and the Manager-in-Charge of Information Technology must oversee implementation and make sure client accounts are protected. A firm that waits until the end of the implementation period will still need to account for any losses that occur in the meantime.
How Hong Kong compares with the region
Regulators across APAC have been restricting the use of SMS OTP. Bank Negara Malaysia made it non-compliant as a standalone factor under its updated RMiT guidelines. In Singapore, MAS and the Association of Banks phased it out for digital-token users in 2024. Hong Kong’s HKMA pushed banks towards in-app authentication for high-risk e-banking activity. In the Philippines, the BSP banned SMS and email OTPs for high-risk transactions under Circular 1213. The UAE’s central bank introduced a full ban and moved liability to banks, while India’s RBI required a dynamic factor for every digital payment from April 2026.
Circular 26EC35 differs in its scope. It comes from a securities regulator and covers licensed virtual asset trading platforms as well as internet brokers. Its prohibition applies to login and device binding instead of a particular transaction-risk tier. A platform cannot exclude supposedly low-value sessions because the requirement applies at the point of access.
How to replace OTP without leaving gaps
The first step is to find every flow in which an OTP appears. Login may be obvious, but device binding, account recovery, contact-detail changes, withdrawal-address whitelisting and step-up prompts often surface later in a migration.
From there, a practical sequence is to introduce passkeys for login with appropriate browser and platform coverage, use an existing passkey to protect device binding, and rebuild recovery around identity verification. Firms can then add the account-event notifications and monitoring required by the circular. Clients who cannot use a passkey will still need a non-SMS alternative, such as a hardware key, a bound device or an in-person check.
Authsignal drops in on top of the identity stack you already run, whether that is Auth0, Cognito, Azure AD B2C, or a custom build. No user migration. No database changes. Teams can roll out passkeys for login and device binding, use identity verification for enrolment and recovery, and configure step-up rules through a no-code rules engine, all across web, mobile and contact centre from a single orchestration layer.
Air New Zealand deployed Authsignal passkeys on top of their existing identity infrastructure and reached 30%+ passkey opt-in within four months, while reducing SMS dependency by 90%. First Credit Union passed 50% of all authentications through passkeys within weeks of launch. Authsignal processes over 12 million authentications per month for regulated enterprises including MoneyGram and Qualcomm, and holds SOC 2 Type 2, ISO 27001 and FIDO certification.
If your team is preparing for 26EC35, Authsignal can help you map every OTP-dependent flow and replace the weak points across login, device binding and recovery, without re-architecting what you already have. Talk to us about building a migration plan that works for your clients before July 2027.
FAQs
Yes, for the two in-scope flows. The SFC's prohibition targets OTP as a class for client login and device binding, not just SMS or email delivery. A time-based code from an authenticator app can still be entered on a phishing page and relayed in real time. The circular requires phishing-resistant authentication. These are credentials that are cryptographically bound to the legitimate domain and cannot be replayed through a proxy.
The compliance deadline is 8 July 2027, twelve months from the date the circular was issued. Large internet brokers are expected to implement phishing-resistant authentication immediately. All other SFC-licensed internet brokers and virtual asset trading platform operators must comply as soon as practicable within that window.
The circular names passkeys and bound devices as acceptable approaches. Passkeys use public-key cryptography scoped to the legitimate domain, which prevents the real-time relay attacks that motivated the ban. Bound devices rely on cryptographic verification of a registered device combined with an additional factor such as biometrics. Hardware security keys are also consistent with the phishing-resistant standard.
No. Firms do not need to force re-enrolment of devices that are already bound. The requirement applies to new logins, new device bindings and credential recovery from the implementation date forward.
The OTP prohibition specifically targets client login and device binding. Other step-up scenarios are not directly covered by this circular. However, any remaining OTP path becomes the weakest link in the authentication chain. If an attacker can phish a step-up code to change a withdrawal address, the strength of the login flow is moot.
The SFC names the Manager-in-Charge of Overall Management and Oversight and the Manager-in-Charge of Information Technology as the senior individuals responsible for implementation. The circular states that the SFC will hold firms accountable for client losses arising from control failures, even during the implementation period.
.svg)
