Passkeys and MFA with Keycloak: going passwordless in your customer portal

Your B2B portal can be built with all the care in the world — the passwords of your users are not. The FIDO Alliance attributes around 80 percent of all data breaches to passwords: harvested through phishing mails, reused across dozens of services, tried out at scale via credential stuffing. A customer portal inherits this risk with every single login field.

Add a quiet cost block: the password reset. Gartner has estimated for years that 20 to 50 percent of all helpdesk calls stem from forgotten passwords; Forrester put the cost for large organizations at around 70 US dollars per reset. Even if your numbers are lower: every reset is a customer who, at that moment, is waiting instead of ordering.

And phishing stopped targeting only large corporations long ago: fake portal logins are a standard tool in attacks on mid-sized companies, and stolen B2B credentials are actively traded. A password field in your customer portal remains a permanently open entry point — no matter how well the rest of the application is hardened.

For exactly this problem there is now an industry standard: passkeys. If your portal runs on Keycloak, you already own the required technology. This article answers three questions: What are passkeys? What can Keycloak do as of September 2026? And what does a tiered model look like that brings your user groups along instead of overwhelming them?

A passkey is a passwordless login: instead of a string of characters someone has to know and keep secret, the user's device holds a cryptographic key. At login, users confirm the same way they unlock their smartphone — fingerprint, face recognition, or PIN. Under the hood sit WebAuthn, a W3C standard since 2019, plus the FIDO2 specifications of the FIDO Alliance.

The core difference to a password: there is nothing left for an attacker to steal. The secret key never leaves the device, and it only answers the domain it was created for. A deceptively real phishing copy of your portal runs into a void. That is why passkeys count as phishing-resistant — not merely phishing-hindering like an SMS or app code.

One point matters for perspective: a passkey is not just more convenient, it is already multi-factor at its core. The device is the possession factor; unlocking it via biometrics or PIN is the second. Passwordless login does not abolish MFA — it folds it into a single gesture.

You should know two variants. Synced passkeys live in the user's keychain (iCloud Keychain, Google Password Manager, 1Password) and travel to new devices automatically. Device-bound passkeys sit in hardware keys such as a YubiKey and never leave them. The former are the convenient choice for portal customers, the latter the hard currency for admin access.

On adoption: in a 2024 FIDO survey, 53 percent of respondents said they had activated passkeys on at least one account. Your portal users know the procedure from Google, PayPal, or their Apple account — introducing passkeys at your company does not mean importing an exotic method, it means bringing a familiar convenience into B2B.

First, some orientation: what Keycloak delivers as an open-source IAM in general is covered in our overview What is Keycloak?. Here we focus on a single question: how mature is passwordless login there? The short answer: mature.

Keycloak has handled WebAuthn as a two-factor and passwordless method for years. Passkeys in today's sense shipped as a preview feature from version 23 (late 2023). The step to production readiness is documented in the Keycloak 26.4 announcement from September 2025: since then, the passkey integration is officially supported.

Development continues: version 26.7 from July 2026 brought the discoverable-credential setting per the current WebAuthn specification and improved compatibility with iCloud Keychain, Google Password Manager, and 1Password. As of today (Keycloak 26.7), passkeys, WebAuthn, and recovery codes are supported features that are active by default.

The most important new feature for customers is called Conditional UI: the browser suggests the passkey right in the login field, just as a password manager offers saved credentials — one tap, done. The Modal UI remains alongside it: the classic dialog window that mainly serves hardware keys with a PIN or biometric prompt.

The rebuild is pleasantly unspectacular: you do not have to touch the standard browser flow. You enable passkeys in the realm's WebAuthn passwordless policy and offer registration as a required action. A new conditional authenticator also skips the second-factor prompt when a user has already signed in via passkey — double security without a double hurdle.

For your buying decision this means: passkey capability in Keycloak is not a paid extra and not an add-on tier, but part of the standard equipment — including Conditional UI, policies, and admin tooling. The question is no longer whether the technology is ready, but how you roll it out.

Passkeys are the target state, but no portal jumps there in a day. In between sits classic multi-factor authentication — and Keycloak covers the full range:

On top come brute-force protection, session policies, and step-up authentication: Keycloak can demand a stronger login for critical actions than for normal portal access — say, a passkey confirmation before releasing a large order. Which protocols carry all this toward your applications is sorted out in SAML vs. OIDC.

Treating all users the same would be convenient, but wrong: a buyer who orders once a month has a different risk profile than the admin of your realm. Here is a tiered model that has proven itself in our portal projects — explicitly an assessment, not dogma:

Portal customers: the password stays for now, and the passkey is actively offered after login. OTP remains open to security-conscious customers on a voluntary basis. The goal is added convenience, not re-education.

Back office and employees: mandatory MFA from day one — OTP as the minimum, the passkey as the more convenient alternative that, in our experience, wins on its own.

Admins and key roles: device-bound hardware keys plus recovery codes in the safe. Cloud sync is deliberately unwanted here: the key to your identity system does not belong in a shared keychain.

The lever for implementation is called required actions: per group, you define whether passkey registration is offered, recommended, or mandatory. Your security policy becomes a configurable process instead of a project per change.

Technically, you model these tiers with authentication flows and conditions — per role, per client, per context. How the portal behind it hooks into ERP and inventory management via SSO is a topic of its own: we cover it in a separate article on customer portal SSO with ERP integration.

So much for the technology. Success or frustration is decided by the rollout — and here we speak from project experience, not from the datasheet. Three points where passkey introductions get stuck in practice:

Never start with a hard password ban. The realistic path is coexistence: the passkey as the promoted default option, the password as fallback, recovery codes as the emergency anchor. Only once a user group measurably signs in passwordless most of the time do you withdraw the password there. Keycloak allows exactly this gradual pace — per flow, per group, without an all-or-nothing decision.

What happens when the smartphone stays behind in a taxi? With synced passkeys the answer is relaxed: the new device brings the keys along via the keychain. It gets critical with device-bound keys and with users on unmanaged devices — there, recovery codes belong to registration as a mandatory step. Otherwise you merely trade password-reset tickets for passkey-reset tickets.

One B2B peculiarity remains: at the front desk or in the workshop, several people sometimes share one account. Such shared logins do not mix with biometrics on a personal device. Clarify before the rollout where they exist — and whether they are not a case for separate accounts anyway.

Our experience: coercion creates tickets, a good moment creates adoption. The best time to offer the passkey: right after a successful login, ideally after a password reset — the pain is fresh, and the argument “never forget a password again” lands.

Internal users move faster: there, in our assessment, the passkey wins within a few weeks, as soon as the first colleagues show off the quicker login. With portal customers, plan in months, not weeks, and measure progress: share of passwordless logins, reset tickets per month, abandoned registrations. The rule of thumb: passwordless is a migration, not a switch.

If your portal already runs on Keycloak, the entry point is small: activate the policy, define a pilot group, promote registration — an effort of days, not months. If the portal is still ahead of you, plan the identity layer in from day one: building customer portals with Keycloak, SSO, and ERP integration is exactly what we do.

Want to know which tiered model fits your user groups, or whether your existing setup is passkey-ready? Then book a free consultation call: 30 minutes, a concrete assessment, no slide theater.