Passkey sign-in turns business banking login into phishing resistance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Secfense's blog post: Bank BNP Paribas introduced passkey sign-in for GOonline Biznes, showing how phishing-resistant authentication can be added to an established business banking platform without changing transaction authorization.

Why it matters: IAM and security teams should treat passkey rollout as an authentication and recovery programme, not just a sign-in feature, because adoption, fallback paths and account recovery determine whether phishing resistance holds in practice.

Context

Passkeys replace reusable passwords with device-bound authenticators that only work for the intended relying party. In banking, that changes the attack surface because a lookalike site can capture a password, but it cannot replay a domain-bound passkey on its own.

The governance question is not whether passkeys are more secure in theory. It is how a live service preserves user choice, recovery paths, and transaction approval without creating weak fallback routes that undo the phishing-resistant login layer.

Key questions

Q: How do passkeys stop phishing in banking sign-in?

A: Passkeys stop phishing by binding sign-in to the legitimate website’s origin and using public-key cryptography, so a fake banking page cannot collect a reusable secret. The private key stays on the client device or authenticator, while the bank verifies a signed challenge. That blocks password replay, credential stuffing and many man-in-the-middle attempts during cryptographic sign-in.

Q: What is the difference between passkeys and passwords for customer authentication?

A: Passkeys are device-bound cryptographic credentials that authenticate a user without exposing a shared secret to the server, while passwords are reusable secrets that users type and servers must store or validate. Passkeys are harder to phish, less useful to attackers after theft, and better suited to modern step-up and recovery workflows in financial services.

Q: How should banks handle passkey recovery for clients?

A: Banks should treat passkey recovery as an identity recovery process, not a simple reset. Recovery should require step-up verification, a separately enrolled factor, and review of account recovery events before issuing a new passkey or revoking the old one. Weak recovery can let an attacker who controls email, SMS, or a support channel replace the client’s authentication method.

Q: Why do fallback authentication methods create so much risk after passkey rollout?

A: Fallback methods create risk because attackers target the weakest available route, not the strongest one. If SMS, push, QR fallback, or weak recovery still exists, the attacker can steer the user into that path and defeat the stronger factor indirectly. A passkey deployment is only as resistant as its recovery and fallback design.

Technical breakdown

How domain binding blocks lookalike-site replay

A passkey is a phishing-resistant credential pair stored on a device or hardware key. During authentication, the client proves possession of the private key and the authenticator checks that the request comes from the expected domain before it signs. That domain binding is what breaks the common phishing pattern: a fake banking site can present a login form, but it cannot convince the authenticator to produce a valid assertion for the real banking domain. Because the browser and authenticator cooperate, the credential is not exposed to the site in reusable form. See the Passwordless and Passkeys Guide.

Practical implication: Treat phishing resistance as a domain and relying-party control problem, not just a user experience improvement.

Why passkeys can coexist with password fallback

Many banking platforms cannot switch every client at once, so passkeys are often introduced alongside existing login methods. That coexistence is workable only if the new method becomes the preferred path rather than an optional overlay with identical exposure. If password sign-in remains broadly available, the phishing-resistant layer reduces risk for adopters but does not eliminate password theft risk for the service as a whole. The real design issue is whether fallback use is constrained, monitored, and eventually reduced as adoption grows. See the Authentication Maturity Model.

Practical implication: Set explicit adoption and fallback thresholds so password sign-in does not become the permanent weak link.

How transaction authorization stays separate from sign-in

This rollout keeps authentication and transaction approval as different control points. Sign-in establishes the user session, while transaction authorization continues through the method already used by the company. That separation matters because it lets the bank change the login factor without destabilising payment workflows or approval processes that clients already depend on. It also avoids conflating identity proofing with high-risk transaction confirmation, which are related but not interchangeable controls in business banking. The design preserves operational continuity while tightening the primary entry point. See the Authentication Guide.

Practical implication: Review whether authentication and transaction approval are too tightly coupled in your own banking or payments flows.

NHI Mgmt Group analysis

Passkeys shift the attack surface from shared secrets to device-bound trust. That is a material improvement for business banking because phishing succeeds when the same secret can be replayed elsewhere. Once the credential is tied to the bank’s domain and anchored to a trusted device, the attacker loses the reusable artifact that password theft depends on. The practical implication is that identity teams should judge passkey projects by replay resistance, not by enrollment counts alone.

Fallback design determines whether phishing resistance survives contact with operations. A passkey programme can look strong on paper and still leave the account ecosystem exposed if password sign-in remains an unrestricted parallel path. Recovery, step-up, and help-desk flows become part of the security boundary, not afterthoughts. The implication is that access policy must govern the entire sign-in and recovery lifecycle, not only the preferred authentication method.

Authentication and transaction authorization should not be forced into one control plane. Bank-facing workflows often need stronger sign-in without disrupting established approval methods, and this separation is the right governance instinct. It lets organisations modernise the front door while preserving the business logic that controls high-risk actions. The implication is that IAM and PAM teams should map which controls protect session entry and which controls govern the action itself.

Passkey adoption in banking is now a lifecycle issue, not a pilot issue. The real work starts after initial rollout, when client registration, device changes, recovery, and support requests begin to shape risk. If those processes are weak, the phishing-resistant layer becomes a narrow technical island inside a broader identity journey that still depends on fragile exceptions. The implication is that banks need lifecycle governance around passkeys from day one.

Domain-bound authentication should become the baseline expectation for customer-facing banking access. Passwords remain easy to phish because they are portable by design, while passkeys bind the authenticator to the intended service. That makes them a better fit for high-trust financial access where the relying party is known and stable. The implication is that business banking programmes should treat passkeys as a default architecture choice for sign-in hardening.

What this signals

Phishing-resistant authentication becomes meaningful only when the fallback path is governed. Many identity programmes will add passkeys first and discover later that recovery, help desk handling and password coexistence still carry most of the risk. The next stage for practitioners is to manage the entire access journey as one policy surface, not a set of disconnected login options.

Business banking will increasingly judge authentication by whether it survives spoofed sites, device churn and user support workflows. That shifts the implementation question from feature adoption to governance maturity, especially where transaction approval must remain stable while sign-in changes.

For practitioners

• Define the passkey rollout scope Start with sign-in only, then decide where password fallback remains acceptable and where it should be removed later.
• Constrain recovery and registration paths Treat account recovery, additional device enrolment and help-desk resets as part of the authentication boundary, because weak recovery can nullify phishing-resistant sign-in.
• Separate login from approval controls Keep transaction authorization distinct from the sign-in method so that stronger authentication does not break established approval workflows.
• Stage adoption and measure fallback use Roll out passkeys in phases, then track registration, sign-in success and the remaining use of passwords to identify where operational friction is driving exceptions.

Key takeaways

• Passkey sign-in materially improves phishing resistance in business banking because the credential is tied to the legitimate domain and a trusted device.
• The hardest part of deployment is not the primary login factor but the recovery, fallback and support paths that can reintroduce the same risk.
• Banks and IAM teams should separate sign-in hardening from transaction authorization so they can modernise access without destabilising business processes.

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Workforce Identity Security Guide · Authentication Guide · Authentication Maturity Model

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• 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.
• Public-Key Cryptography: Public-key cryptography uses a paired public key and private key to prove identity without sharing the same secret during login. The public key can be stored by the service, while the private key stays on the user device or authenticator. Its security depends on strong key generation, device protection, and safe lifecycle management.
• Device-bound Credential: A device-bound credential is a key or token that can only be used from an approved device or authenticator. In practice, it reduces replay and theft risk, but it also raises the stakes of enrollment, attestation, and revocation because the credential can act repeatedly until invalidated.

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.