$1,000,000 in security audit grants are live now, Apply here →

← Resource Hub

SFC Passkey Requirement: What Must Be Live by July 8, 2027

By the Guardian team Updated 6 min read

SFC Passkey Requirement: What Must Be Live by July 8, 2027

Quick answer. As soon as practicable, and by July 8, 2027 at the latest. SFC circular 26EC35 says OTP is not phishing resistant and should not be used for client login or device binding. Monitoring upgrades are expected now.

Watch: SFC Passkey Requirement: What Must Be Live by July 8, 2027 1:45
Video transcript

Hong Kong's SFC says one-time passwords are not phishing resistant. Client login should move to options like passkeys or bound devices by July 8, 2027 at the latest.

Phishing made up 57 percent of H K CERT incidents in 2025. Fake sites harvested passwords and OTPs, which the SFC suspects were used to trade.

Any code a client can retype, a fake site can reuse. A passkey only works with its own site or app.

Device binding will need robust verification, such as an existing passkey, a liveness checked selfie, an ID document with a selfie match, or an in person visit.

Accounts are generally limited to three passkeys and three devices, with an idle timeout clients cannot disable. Logins and new bindings should trigger prompt alerts.

Much of this applies now. Surveillance, client alerts and incident reporting are expected immediately, and large internet brokers should switch login now too.

If a firm fails to stop large-scale unauthorized transactions, the SFC says it will hold that firm accountable for its clients' losses.

Test each takeover path. Password and OTP login should fail. A lookalike domain should not accept the passkey. Recovery should never fall back to OTP. Time a replayed takeover to suspension.

Guardian pentests these takeover paths, from device binding and recovery to sessions and withdrawals. Read the full article, or talk to Guardian.

On July 9, 2026, Hong Kong’s Securities and Futures Commission (SFC) told internet brokers and licensed crypto platforms to move client login off one-time passwords (OTPs).

Its examples of acceptable replacements are passkeys and securely bound devices. The latest date for the login change is July 8, 2027; most of the rest applies today.

This article explains the technical and security side of the SFC’s circular on robust authentication methods and monitoring and surveillance measures (26EC35). It is not legal advice; confirm how it applies to you with counsel.

What the Circular Says

Who it covers

The circular is addressed to licensed corporations and SFC-licensed virtual asset service providers (VASPs). For now, VASPs means virtual asset trading platform (VATP) operators.

On the securities side it reaches licensed corporations engaged in internet trading under Types 1, 2, 3 or 9.

It sets four expected standards:

  1. Prevention: phishing-resistant client login and device binding.
  2. Detection: surveillance of trades and withdrawals, and timely client alerts.
  3. Response: containment, client notice and reporting to the SFC.
  4. Awareness: warning clients about common attacks.

Senior management is “ultimately responsible”, in particular the Managers-in-Charge of Overall Management and Oversight and of Information Technology.

Related: our guides to the SFC’s custody circular (25EC44) and AI-enabled cyberattacks circular (26EC32).

Why OTP is out

Phishing made up 57% of incidents reported to HKCERT in 2025, the circular notes.

That year, large-scale SMS campaigns impersonated brokers and cited fake requests from regulators. Clients entered their passwords and OTPs on fake websites.

The SFC suspects a man-in-the-middle attack then used them to enter accounts and trade.

Any code a person can read and retype has this flaw. A fake site can collect it and use it while it is still valid.

The SFC now says OTP is not phishing resistant and should not be used for login or device binding. Devices already bound need not be rebound.

Passkeys and Bound Devices

The Appendix gives two examples: passkeys and bound devices. Either can serve as the “what the client has” factor in two-factor login.

Passkeys

A passkey is a public-key credential kept on the client’s device, a hardware security key or a passkey manager. It works only with the site or app it was created for.

Solutions, built in-house or bought, should be FIDO certified. Firms should also:

  • verify identity strongly before a passkey is registered;
  • add passkeys only via an existing passkey or robust verification;
  • manage revocation and recovery of lost or compromised passkeys; and
  • stop synced passkeys being abused for unauthorized access.

Bound devices

Device binding links a phone or computer to the account through securely enrolled device attributes. It is only as strong as the check used to bind it.

After July 8, 2027, binding needs robust verification, not a password and OTP. The SFC’s examples:

  1. An existing passkey, used cross-device.
  2. A liveness-checked selfie, matched to the firm’s onboarding records, not the phone’s biometrics.
  3. An identity document checked against records, plus a selfie matched to its photo.
  4. A visit to the firm’s office in person.

Lost devices need a clear path: de-register first, then bind the replacement robustly.

Limits, Timeouts and Alerts

The circular restates two existing controls and sets expectations for alerts:

  • Three and three: generally at most three passkeys and three devices per account.
  • Session timeout: clients should not be able to disable it; idle limit, for example 30 minutes.
  • Alerts: prompt notice of logins, new-device logins, bindings and passkey changes, over several channels.
  • Confirmation: strongly encouraged before further trading after material changes, such as a new device.

Going beyond three needs an adequate assessment. A longer idle timeout needs a trading reason and close monitoring.

Surveillance and Reporting

Transaction monitoring should set thresholds from each client’s profile, history, devices and login patterns. It covers withdrawals as well as orders.

Red flags include trades out of pattern or at unusual hours, and unusual trades soon after a password reset, contact change or new device.

Login and binding logs should capture device IDs and be reviewed promptly. Watch for:

  • binding requests from unusual locations;
  • several client accounts bound to one device;
  • logins from multiple locations within a short period;
  • unusually long login sessions.

On an irregularity, verify with the client directly and suspend the account where appropriate.

Incidents

Procedures should halt unauthorized activity, safeguard assets and notify affected clients. Hacking incidents should be reported to the SFC immediately, followed by root cause analysis.

The stakes are explicit. A firm needs adequate measures to prevent, detect and stop large-scale unauthorized transactions after a hack.

If it fails, the SFC “will hold the relevant firm accountable for the losses suffered by its clients”.

For the first hour, see our crypto exchange incident response plan.

Timeline: Now and July 2027

Measure When
Notifications, surveillance, response and reportingImmediately; the SFC will be pragmatic where systems need time
Client awareness of phishingAs soon as practicable
Phishing-resistant login and device bindingAs soon as practicable; July 8, 2027 at the latest
Phishing-resistant login and binding at large internet brokersImmediately

During the 12 months, firms should test the new methods before deployment, roll them out to all clients and explain the change.

Until then, OTP remains a phishing risk, so monitoring for irregular logins and unauthorized trades should be stepped up.

On suspected fraud, firms “must take immediate action to suspend or restrict account access”.

A firm that expects to miss the deadline should tell its case officer immediately.

A Test Plan for Account Takeover

Each test follows a path the circular describes. Run them on every channel: web, desktop and mobile.

  1. After cutover, log in with password and OTP alone. It should fail.
  2. Serve the login page from a lookalike domain. The passkey should not work.
  3. Bind a new device with password and OTP. It should fail.
  4. From a live session, try to add a passkey without step-up verification.
  5. Call the hotline as an impostor and ask to de-register a device.
  6. Run account recovery end to end, looking for a fallback to OTP.
  7. Change contact details, then bind a device. Was the old contact alerted?
  8. Replay a takeover: new device, new location, withdrawal. Time it to suspension.
  9. Run a tabletop from first alert to the SFC report.

Keep a dated record of each result. For the wider scope of an exchange assessment, see crypto exchange pentesting.

How Guardian Helps

Guardian’s web application and API pentests attack login and recovery flows, sessions and tokens, 2FA steps and withdrawals.

Guardian maps every function a user can reach and tests each one, so passkey registration and device binding are tested like any other flow.

Guardian’s regulatory readiness assessment lists each provision with the control that meets it, the evidence that proves it, and any gap. Its Hong Kong map includes the 26EC35 deadline.

Frequently Asked Questions

When is the SFC passkey deadline?

As soon as practicable, and no later than July 8, 2027. Large internet brokers are expected to implement phishing-resistant login immediately, and monitoring and reporting enhancements are expected now.

Can SMS or email OTP still be used for login?

The SFC says OTP is not phishing resistant and should not be used for login or device binding. It acknowledges OTP use continuing during the 12-month implementation period, with enhanced monitoring meanwhile.

Do passkeys have to be FIDO certified?

The Appendix says passkey solutions, built in-house or by a third party, should be subject to appropriate certification, that is, FIDO certification.

How many devices can a client bind?

Generally no more than three passkeys and three devices per account. Requests for more need an adequate assessment before approval.

Sources

Test your login paths before the SFC does

Guardian pentests the login, recovery, session and withdrawal flows circular 26EC35 describes, and maps the evidence to each provision.