Phishing-Resistant MFA for Japan-Based Enterprises

Most organizations that believe they’ve already solved MFA are still one convincing phishing page away from a compromised account, because the MFA they deployed is the kind that can be phished. SMS codes, authenticator app codes, and simple approve/deny push notifications all have the same underlying weakness: the credential they produce can be captured or the approval can be tricked, then reused by an attacker who was never anywhere near the real login page. Phishing-resistant MFA closes that gap by design rather than by user vigilance, and for Japan-based enterprises running Microsoft 365 and Salesforce, 2026 is the year vendor enforcement is making the migration mandatory rather than optional.

What Phishing-Resistant MFA Actually Means (FIDO2/Passkeys vs. OTP)

“Phishing-resistant” is a specific technical claim, not a marketing label attached to any MFA method. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) defines it narrowly: an authentication method is phishing resistant only if the cryptographic exchange binds to the relying party’s origin domain, so that a credential intercepted or replayed from a phishing site cannot be used to authenticate against the real one¹. By that definition, CISA recognizes exactly two categories as phishing resistant — FIDO2/WebAuthn (which includes passkeys and hardware security keys) and PKI-based authentication such as smart cards or PIV/CAC credentials¹.

Everything else commonly labeled “MFA” falls outside that bar, including methods that feel modern:

• SMS and voice OTP — a code sent to a phone number, which a phishing page can prompt the victim to type in, or which can be intercepted through SIM-swapping.
• App-based TOTP codes (Google Authenticator, Microsoft Authenticator in code-generation mode) — functionally identical to SMS from a phishing-resistance standpoint: it’s still a string of digits a victim can be tricked into typing into a fake page.
• Simple push notifications — an approve/deny prompt with no context, which relies entirely on the user correctly recognizing that a login attempt isn’t theirs. MFA fatigue attacks exploit exactly this by sending repeated prompts until one gets approved.
• Number-matching push — an improvement over simple push, since it requires the user to enter a number shown on the real login screen, but it still depends on user judgment rather than cryptographic origin binding, and CISA does not classify it as phishing resistant.

FIDO2 and passkeys work differently because the check happens in the protocol, not in the user’s judgment. When a user authenticates, their device and the relying party perform a cryptographic exchange that includes the domain making the request. If that domain doesn’t match the one the credential was registered to, the authenticator simply won’t respond — there’s no code to intercept and no approval prompt a confused user can accidentally grant to the wrong party. Microsoft’s own guidance for planning a phishing-resistant passwordless deployment describes this as the core reason passkeys and FIDO2 security keys close the phishing gap that password-plus-OTP setups leave open².

Why SMS and App-OTP MFA Still Get Phished in Japan-Targeted Attacks

The practical failure mode is an adversary-in-the-middle (AiTM) phishing kit: a fake login page that sits between the victim and the real Microsoft 365 or Salesforce sign-in flow, passing the victim’s password and OTP straight through to the real service in real time and capturing the resulting session token. From the victim’s perspective, the login looks completely normal — they typed their password, entered their code, and landed on what looks like their usual dashboard. From the attacker’s perspective, they now hold a valid session, no password reset required, and both the password and the OTP the victim thought protected them are useless as a defense because they were phished, not guessed.

This works against SMS OTP, app-based TOTP, and simple push equally well, because none of the three check the origin of the request. It’s also why account-takeover volume kept climbing industry-wide even as adoption of “MFA” (the OTP kind) increased — the metric organizations were tracking, MFA enrollment, wasn’t measuring the property that actually stops this attack.

For Japan-based enterprises specifically, two factors raise the practical risk of this gap:

• English-language phishing-resistant guidance often lags Japanese-market awareness. Security teams evaluating Microsoft 365 and Salesforce tenant hardening frequently default to whatever MFA method the vendor enables by default, rather than actively selecting the phishing-resistant tier, because the distinction between “has MFA” and “has phishing-resistant MFA” isn’t yet a standard line item in Japan-market security assessments the way it has become in U.S. federal and regulated-industry guidance.
• Formal, vendor-heavy email culture reduces the visual warning signs a phishing page relies on users noticing. A companion piece on this site covers how long CC chains and formal correspondence norms make a spoofed request harder to spot on the email side³; the same dynamic applies to a spoofed login page that closely mirrors the real Microsoft or Salesforce sign-in screen, since users accustomed to routine, formally-worded prompts have less reason to pause and inspect a domain name before entering a code.

Neither factor is a reason to trust users less — it’s a reason not to build a control that depends on users noticing something subtle under time pressure, which is exactly what OTP-based MFA does.

Deploying Phishing-Resistant MFA Across Microsoft 365 and Salesforce in a Japan Office

Both major platforms an enterprise Japan office is likely running are actively pushing phishing-resistant MFA from optional to default or mandatory during 2026, which changes this from a forward-looking hardening project to a compliance deadline for many organizations.

Microsoft 365 / Entra ID. Microsoft has made passkeys the default sign-in method for Entra ID, and as of September 1, 2026, users currently enrolled in SMS or voice authentication are being automatically enabled for passkeys, with a registration prompt appearing at their next MFA sign-in⁴. Microsoft’s guidance for planning a phishing-resistant, passwordless deployment recommends starting with IT and security administrator accounts — the highest-value targets and the accounts where a compromise does the most damage — before expanding to the general user population, and specifically calls out preparing break-glass emergency-access accounts before disabling any legacy MFA method as a fallback². Entra ID accepts both device-bound passkeys (stored in a platform authenticator such as Windows Hello) and synced passkeys, plus dedicated FIDO2 hardware security keys for shared or kiosk-style devices.

Salesforce. Salesforce’s enforcement is more explicitly deadline-driven. As of July 1, 2026, Salesforce requires standard MFA on every login for all users, and for privileged users — anyone holding the System Administrator profile or permissions such as Modify All Data, View All Data, Customize Application, or Author Apex — only phishing-resistant methods built on FIDO2/WebAuthn satisfy the requirement⁵. Existing TOTP-based registrations through Salesforce Authenticator or third-party authenticator apps do not meet this bar for privileged users; those accounts must register a passkey, hardware security key, or certificate-based authentication (CBA) credential, and users who miss the enrollment deadline are blocked from logging in⁵. For a Japan office running Salesforce, this means the admin and integration-owner accounts — often the smallest group of users but the ones with the broadest data access — need to migrate first and on a fixed timeline, not as part of a general rollout scheduled around convenience.

The practical order for a Japan office running both platforms: harden Entra ID and Salesforce admin accounts first (the overlap between “privileged Salesforce user” and “Entra ID admin” is usually high), confirm break-glass accounts are covered by a method that doesn’t depend on the primary MFA system, then expand passkey enrollment to the general user population in Entra ID, which will also simplify Salesforce SSO if Salesforce authentication is federated through Entra ID.

Rollout Challenges: Shared Devices, Legacy Systems, and Vendor Portals

The admin-account migration above is usually the easy part. The friction that stalls phishing-resistant MFA rollouts in practice comes from three categories of exception that don’t fit the “register a passkey on your own device” model:

• Shared and kiosk-style devices. Warehouse scanners, shop-floor terminals, and shared reception workstations don’t have a single owner to register a device-bound passkey against. Hardware FIDO2 security keys — physically assigned per shift or per role rather than per person — are the practical fallback here, but they require a procurement and inventory process most IT teams haven’t previously needed for MFA.
• Legacy and on-premises systems that don’t speak WebAuthn. Older line-of-business applications, some VPN concentrators, and certain on-premises Active Directory-integrated tools may not support FIDO2 natively. These systems typically need either a compensating control (network segmentation, conditional access policies that restrict what a legacy-authenticated session can reach) or a scheduled replacement, and shouldn’t be allowed to quietly extend the OTP fallback window for the accounts that also touch Microsoft 365 or Salesforce.
• Vendor and subcontractor portals outside direct IT control. A Japan office working through a keiretsu or subcontracting chain often has external vendor accounts that authenticate through the vendor’s own identity system, which an internal migration plan has no authority over. The realistic response is to treat vendor-portal access as a separate risk category — scoping what those accounts can reach and monitoring it more closely — rather than blocking an internal rollout on getting a vendor to also adopt phishing-resistant MFA on the same timeline.

None of these three categories are a reason to delay the migration for users who don’t have the exception. The common rollout failure is treating the hard 20% of accounts as a reason to leave the straightforward 80% on OTP for months longer than necessary; the better sequence is to move the straightforward majority immediately and run the shared-device, legacy-system, and vendor-portal exceptions as a parallel, explicitly scoped track.

A Migration Plan From OTP to Passkeys Over Two Quarters

A two-quarter timeline is a realistic default for a mid-size Japan office running both Microsoft 365 and Salesforce, sequenced to put the highest-value accounts first and treat the exceptions above as a bounded, parallel workstream rather than a blocker.

Quarter 1 — Admins, pilots, and exception scoping.

1. Enroll all Entra ID and Salesforce privileged/admin accounts in FIDO2 passkeys or hardware security keys; this is the group Salesforce’s enforcement deadline already applies to, so it doubles as compliance work.
2. Confirm break-glass emergency-access accounts are covered by a method independent of the primary identity provider, so an Entra ID or Salesforce outage doesn’t lock out the accounts needed to respond to it.
3. Pilot passkey enrollment with IT and security teams on their normal devices to surface UX friction before the broader rollout.
4. Inventory shared devices, legacy systems, and vendor-portal accounts, and assign each to shared kiosk-style provisioning, a compensating control, or a separate risk-monitoring track.

Quarter 2 — General rollout and OTP retirement. 5. Roll out passkey registration to the general user population in waves (by department or office), using Entra ID’s registration prompts to drive enrollment rather than a single mass announcement. 6. Provision hardware FIDO2 keys for the shared-device and kiosk category identified in Q1. 7. Confirm enrollment completion per wave before disabling SMS/OTP as a fallback for that group — don’t disable the fallback ahead of confirmed passkey registration, since that trades a phishable method for a lockout risk rather than for the more secure method. 8. Formally retire SMS and app-OTP as an available MFA method once enrollment is confirmed across the user population, leaving legacy-system and vendor-portal exceptions on their separately scoped compensating controls rather than reopening the OTP fallback broadly.

The organizations most likely to miss both Microsoft’s passkey-default transition and Salesforce’s phishing-resistant enforcement deadline for privileged users are the ones that treat this as a single “turn on new MFA” project rather than sequencing admin accounts, general users, and structural exceptions separately. Doing the admin-account migration first also means the highest-value accounts in the tenant are the earliest to stop being phishable, rather than the last.

Sources

• Implementing Phishing-Resistant MFA — CISA
• Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID — Microsoft Learn
• What’s New in Microsoft Entra: June 2026 — Microsoft Community Hub
• Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins — Salesforce Help