Passkeys Enter B2B: From Consumer to Enterprise
Passkeys, pushed into the mainstream by Apple, Google, and Microsoft in 2022–2024, initially gained traction as a consumer authentication method. But B2B adoption accelerated sharply in late 2025, and 2026 can fairly be called "the year Passkeys went enterprise." Okta, Entra ID, Google Workspace, and 1Password Business all support both cross-device Passkeys and synced Passkeys, and have matured to coexist with FIDO2-compliant hardware security keys (YubiKey 5C, Google Titan).
The primary driver of full B2B adoption is phishing resistance. In 2024–2025, AiTM (Adversary-in-the-Middle) phishing kits targeting Japanese companies surged. Traditional TOTP and SMS OTP are vulnerable to session hijacking through a man-in-the-middle proxy — multiple incidents occurred in Japan where thousands of accounts were compromised overnight. Passkeys (WebAuthn) are structurally immune to AiTM because the domain binding means the signature simply cannot be created on a phishing site. The fact that this is guaranteed by the protocol rather than requiring operational vigilance became the basis for executive buy-in.
The tradeoff between synced Passkeys (via iCloud Keychain or Google Password Manager) and device-bound Passkeys (confined to a YubiKey or similar) remains an ongoing discussion. Finance and defense sectors prefer device-bound; broad employee rollouts favor synced Passkeys in practice. The 2025 revision of NIST SP 800-63B recognizing synced Passkeys as AAL2 was a policy tailwind.
WebAuthn Implementation Pitfalls and Account Recovery
The first stumbling block is RP ID (Relying Party ID) design. RP ID is per-domain, so `corp.example.jp` and `portal.example.jp` require separate Passkey registrations. If you want to unify them, you must use the parent domain `example.jp` as the RP ID — but organizations that share the parent domain with their marketing site need to evaluate the impact carefully.
Account recovery is the hardest operational challenge for Passkeys. If recovery design is neglected, weak authentication methods (email OTP, SMS OTP) end up as the backstop, pulling security strength down to the weakest link. The recommended design is three tiers. Minor recovery (logging in from another device): resolved automatically via synced Passkeys. Medium recovery (all devices lost): requires administrator approval and identity document verification. Severe recovery (suspected identity compromise): requires offline in-person identity verification. It's equally important not to route severe recovery through customer support — social engineering attacks against CS staff actually occurred in 2024.
SCIM and Provisioning Automation
SCIM 2.0 automated provisioning is no longer optional — it's a baseline expectation. Syncing from an IdP to each SaaS via SCIM propagates user additions, attribute updates, and deactivations in real time. Major SaaS vendors (Salesforce, Slack, Notion, GitHub Enterprise, Atlassian) all provide SCIM 2.0 out of the box, and receiving-side implementation quality has improved dramatically compared to 2024.
The often-overlooked element in SCIM operations is attribute mapping design. The table mapping IdP-side department, job title, and employment type to SaaS-side groups and permission roles needs to be maintainable by HR and IT together. Okta Workflows and Entra Lifecycle Workflows both provide no-code UIs for expressing this as chains of IF conditions. Attribute transformations encoded in scripts become a classic pattern of being impossible to maintain six months later when something changes. Escaping CSV-based daily syncs is increasingly a point raised in 2026 internal audits.
Why Now for the SAML-to-OIDC Migration
SAML has long been the B2B SSO standard, but as of 2026, new projects default to OIDC. Three reasons. First, mobile and SPA support: SAML's XML redirect flow is cumbersome in mobile-native apps compared to OIDC with PKCE. Second, signing and encryption complexity: SAML's broad XML Signature specification has historically produced implementation divergences that lead to vulnerabilities (XML Signature Wrapping attacks, etc.). Third, OIDC structurally separates authentication (ID Token) from API authorization (Access Token), making permission design cleaner in microservices environments.
That said, eliminating SAML entirely isn't realistic. SAP SuccessFactors, Workday, and parts of Oracle Cloud offer SAML as their only SSO option. The migration strategy is: new deployments on OIDC, existing SAML maintained for now, IdP consolidated to a platform that supports both. The migration pitfall is attribute mapping divergence — when porting the Assertion transformation logic built up over years of SAML operation into OIDC claims, group name collisions and role scope mismatches are common. Always insert a step before migration to enumerate all current SAML Assertion attributes and create an explicit mapping table to OIDC standard claims and custom claims.
Adaptive MFA and Step-Up Authentication
Adaptive MFA dynamically adjusts authentication strength based on request context. Normal sessions pass with Passkey alone; additional authentication is required only when connecting from an unknown device, at an unusual hour, or from a country seen for the first time. Step-up authentication is a subset: for high-risk operations like viewing salary data, pushing to production, or bulk-exporting customer data, the system re-evaluates the current session's authentication strength immediately before the action and requires additional authentication if it falls short. The standard approach is declaring this via OIDC's `acr` (Authentication Context Class Reference) claim: "this operation requires acr=phr (phishing-resistant)."
The hardest design decision is the false-positive tolerance. Too strict and it blocks legitimate work; too lenient and breaches slip through. The author's rule of thumb: start with "known device + known location = Passkey only" and "unknown device = Passkey + step-up," then adjust based on monthly reviews of incident history and false-positive rates.
Uniquely Japanese Friction Points: My Number and Shared Accounts
Rolling out Passkeys, SCIM, and OIDC in Japanese enterprises surfaces cultural friction points not covered in foreign vendor documentation. First: handling employee numbers alongside My Number (個人番号). My Number is strictly restricted by law in its permitted uses — it must not be placed in the IdP's sub claim or SCIM's externalId. Yet production systems that link employee numbers to My Number remain in legacy core systems, and incidents where SCIM sync mistakenly sends My Number to external SaaS have occurred. Attribute mapping tables must include a "prohibited from external disclosure" checklist.
Second: the collision with shared account culture. Small and mid-sized Japanese companies often still have role-based shared accounts like `soumu@` (general affairs) or `keiri@` (accounting). Since Passkeys are bound to an individual's authenticator, assigning a Passkey to a shared account makes it impossible to trace who actually logged in. The migration strategy is to split shared accounts into function accounts (service accounts) and individual accounts: business email reception stays with the function account, but login uses the individual account. If audit log reversibility is the priority, shared logins must be eliminated entirely. Third: the mix of company-issued devices and BYOD — a two-tier setup where synced Passkeys apply to managed devices only and hardware keys are required for BYOD is the practical solution.
Migration Roadmap
A 12–18 month roadmap: Phase 1 (months 0–3) — IdP foundation, SAML/OIDC dual support, inventory of SCIM-capable SaaS. Phase 2 (months 3–6) — Passkey pilot deployment, initial Adaptive MFA policy, SCIM automation for the top 10 SaaS. Phase 3 (months 6–12) — company-wide Passkey rollout, phased deprecation of TOTP/SMS OTP, step-up auth embedded in applications. Phase 4 (months 12–18) — new SAML deployments banned, legacy SAML migrated to OIDC or decommissioned, shared accounts eliminated.
For executive communication, two axes land well: "expected damage from an AiTM incident" and "reduction in audit response overhead." The IdP-centric identity operations platform — integrating HR, ZTNA, and the SaaS portfolio — is being elevated from a project-based initiative to a permanent organizational capability.