From Passkeys to Operational Anti-Phishing Authentication

Shifting from Login Pages to Account Lifecycle

Traditional authentication often focuses on a single question: "Was this login successful?" However, phishing risks do not end upon successful authentication. Attackers may take over an account, register a new device, create a persistent session, update contact details, and execute unauthorized transactions.

Therefore, a mature control framework must simultaneously address five key phases: preventing phishing during login and device registration; detecting anomalies through login, device, and transaction signals; responding immediately by restricting, suspending, revoking, and notifying upon detecting suspicious activity; recovering account access securely after device loss; and continuously raising client awareness to identify phishing SMS, fake websites, and social engineering.

Why Passkeys Mitigate Phishing Risk

SMS OTPs remain fundamentally vulnerable because they represent interceptable and relayable secrets. When users enter OTPs on phishing sites, attackers execute real-time Man-in-the-Middle (MitM) attacks. The SFC explicitly stated that OTPs are not phishing-resistant solutions and should not be used for key procedures like client login or device binding.

Passkeys rely on public-key cryptography. Private keys remain secure on client devices or credential managers, while the server only stores public keys. Passkey challenges bind strictly to legitimate origins/domains during registration and authentication, preventing phishing sites from intercepting usable authentication responses.

For clients, authentication is as simple as biometric or PIN unlock; for platforms, it transforms access from entering relayable secrets to responding to origin-bound cryptographic challenges. This is why the SFC Annex highlights Passkeys as an acceptable method.

Key Takeaways from the SFC Annex: Multiple Paths for Device Binding

The SFC Annex does not mandate a single product or technique as the sole solution. Instead, it provides acceptable robust verification method examples. This offers flexibility while increasing design responsibility: institutions must select appropriate methods based on platform, client profile, risk, and operational capability.

The acceptable device binding methods listed in the Annex can be grouped into four categories:

The Annex also clarifies that after implementation, existing clients without bound devices can re-bind via robust verification methods. For lost, stolen, replaced, or inaccessible devices, service providers should establish clear revocation and recovery policies with clear user guidance.

Synced Passkeys Do Not Equal Manageable Device Endpoints

Relying solely on Passkeys is still insufficient to handle continuous access control. Synced Passkeys may be available across multiple client devices, while the server might not have visibility into all physical devices managed by Apple or Google keychains. Therefore, successful authentication should not directly imply that a new client device has obtained authorization for existing endpoints.

A more robust approach is to establish a server-side managed endpoint layer. Each endpoint should possess an independent binding public key, active or revoked status, session version, and an auditable event timeline. This allows firms to enumerate, restrict, revoke, and track continuous access rights, rather than merely recording that a Passkey verification succeeded.

The SFC guidelines state that, generally, clients should not be permitted to bind or register more than three Passkeys and/or three devices; any request exceeding this limit requires thorough assessment. While industry practitioners should avoid treating recommendations as rigid hard rules, a fourth client should never automatically receive authorization without additional verification and approval.

New Endpoint Activation: Four Gates, Not One Button

New device registration should be treated as a high-risk authorization event rather than a routine login extension. The following four backend gates can be implemented:

Only after all conditions pass successfully can the endpoint transition to active status, allowing the system to record the binding public key and issue an endpoint-bound session. If the result is pending, failed, or timed out, it should trigger re-verification, manual review, or policy rejection. SDK or H5 UI completion screens must never serve as final authorization proof.

Rule-Based Controls: Turning Regulatory Requirements into Testable Decisions

When financial institutions adopt policy-driven authentication platforms like OneSpan Digipass S3, the true deliverable is not merely a feature checklist supporting Passkeys, but a testable, replayable, and auditable control matrix. Public data from OneSpan indicates that Digipass S3 supports Passkey/FIDO, policy-driven registration and authentication, device and risk signals, recovery, and audit trails.

In practice, an Authenticator Policy determines allowed FIDO or Passkey authenticators; a Registration Policy governs when new endpoint registration is permitted and whether existing Passkeys, eIDV, or manual review are required; an Authentication Policy defines which login flows must mandate Passkey usage and when OTPs can no longer satisfy login criteria during transition; and a Policy Set binds multi-layered policies to specific web, mobile, or desktop applications.

Every rule should be equipped with positive and negative test scenarios:

Every policy change should follow a lifecycle of Define, Approve, Test, Monitor, and Tune/Rollback. The evidence package should include application/policy maps, rule inventories, version history, change approvals, positive/negative test logs, rule match events, notification delivery logs, case disposition records, and periodic management reviews. Only with such evidence can security controls be replayed, validated, and continuously tuned.

True Compliance Is Observable, Intervenable, and Recoverable

The SFC requires timely client notifications for high-risk activities such as successful logins, new device logins, new device bindings, and Passkey creation or revocation, alongside monitoring suspicious logins and unusual transactions. When necessary, institutions must directly verify with clients, restrict, or suspend accounts.

Therefore, authentication services, trading platforms, and operational teams must form a closed loop. Auditable signals include unusual geographic locations, multiple logins across distant locations within short timeframes, single devices binding multiple accounts, rapid transactions following new endpoint binding, transactions deviating from user patterns, and abnormally long sessions. These signals should not merely sit on dashboards; they must trigger explicit actions: Allow, Step-up, Restrict, Suspend, or Manual Review.

Similarly, trusted endpoint management and all-endpoints-lost recovery must be segregated. If a client still retains one secure endpoint, fresh authentication can be required to revoke other endpoints, invalidating revoked endpoint sessions immediately while notifying the client. If all endpoints are lost, the user enters a high-assurance recovery process, such as eIDV, manual review by customer support, old session revocation, and complete audit logging of the recovery timeline.

Cloud Services Are Not Automatic Compliance

Adopting cloud authentication services does not mean financial institutions can outsource accountability. Institutions must still define data exchange boundaries, data usage, minimum necessary data, service locations, retention periods, administrative access rights, SLAs, incident reporting, audit rights, and contingency plans for service disruptions.

Particularly when employing biometric data or identity document verification, data governance must be designed in tandem with technical flows. Who can view raw images? What does the service provider store? Does the firm receive raw data, verification results, or risk scores? What are the manual handling and client notification SOPs when recovery fails or services are unavailable? These questions must be explicitly answered in contracts, DPAs, privacy impact assessments, and operational runbooks.

Counting Down to July 8, 2027: What Should Begin Now?

The SFC mandates the implementation of robust authentication solutions within 12 months of circular issuance and no later than July 8, 2027; major internet brokerages are expected to implement them immediately. For the industry, the most pragmatic approach is not waiting to complete all systems in a single go, but adopting a risk-based, phased roadmap.