WhatsApp has begun rolling out a set of account security enhancements, most notably support for multiple passkeys and a strengthened two-step verification (2SV) flow. On the surface this is consumer-app news. In practice, it matters to every organization whose executives, employees, or customers use WhatsApp for business communications — and in 2026, that is effectively every organization with a global footprint.
WhatsApp remains one of the highest-value account-takeover targets on the planet. With roughly three billion users, the platform is the default business communications channel across Latin America, Africa, the Middle East, South Asia, and much of Europe. Threat actors have monetized WhatsApp hijacking for years: compromised accounts are used for fraud against the victim's contact list, for pivoting into business relationships, for intercepting verification codes belonging to other services, and as initial access for social-engineering campaigns against enterprises. The dominant takeover vector has never been a cryptographic break of WhatsApp's Signal-protocol encryption — it has been registration hijacking: re-registering a victim's phone number on an attacker-controlled device using a phished or intercepted SMS verification code, often chained with SIM swapping.
These new features directly attack that kill chain. But like every security control, they only deliver value if they are actually enabled, correctly configured, and reinforced by adjacent controls. This post breaks down what changed, why it matters from a defensive standpoint, and the concrete steps security teams should take — both for their own staff and for executive-protection programs.
Technical Analysis: What Actually Changed
Multiple passkeys
WhatsApp introduced passkey support for account access beginning in 2023–2024, but the initial implementation was limited — notably, a single passkey per account and inconsistent support across platforms (Android first, iOS later). The current rollout removes that constraint: users can now register multiple passkeys on a single account.
Why this matters operationally:
- Multi-device reality. Users legitimately operate across a phone, a tablet, and one or more desktops. A single-passkey model forced users into a corner: either the passkey lived on one device and every other device fell back to weaker re-verification, or users avoided passkeys entirely. Multiple passkeys let each trusted device hold its own credential, eliminating the incentive to fall back to SMS-based re-verification.
- Loss and recovery resilience. A single passkey stored only on a phone is a single point of failure. Multiple passkeys — including one stored in a password manager or on a hardware-backed credential store — provide a recovery path that does not route through the phone number, which is precisely the asset an attacker controls after a SIM swap.
- Phishing resistance. Passkeys are FIDO2/WebAuthn credentials. They are origin-bound and cannot be replayed on a lookalike domain. This structurally defeats the OTP-phishing kits (the same class of tooling used in the widespread adversary-in-the-middle phishing campaigns we've tracked against Microsoft 365 and Google accounts) when applied to WhatsApp re-registration flows.
Stronger two-step verification
WhatsApp's legacy two-step verification is a user-set 6-digit PIN required when re-registering the phone number on a new device. It has long been the single most effective control against registration hijacking — and long been undermined by weak adoption and weak PINs.
The strengthened 2SV rollout reportedly tightens this flow: improved prompts and enforcement during registration events, better surfacing of the setting, and — critically — the ability to bind an email address as a recovery mechanism so that a forgotten PIN does not force account reset into a weaker state. From a defender's perspective, the email-binding piece is significant: historically, users who forgot their 2SV PIN were pushed into waiting periods or recovery flows that attackers could also attempt to abuse. A properly bound recovery email on a hardened account shifts recovery trust away from the phone number.
The threat model this addresses
The attack chain these features disrupt looks like this in the incidents we've worked:
- SIM swap or number port-out — attacker socially engineers the victim's mobile carrier (or uses an insider) to move the victim's number to an attacker-controlled SIM/eSIM. Alternatively, the attacker simply obtains an SMS verification code via phishing, smishing, or an OTP-bot service.
- Registration attempt — attacker installs WhatsApp, enters the victim's number, and receives the SMS code on the swapped SIM.
- 2SV prompt — if the victim had a 2SV PIN set, the attacker is stopped here. If not, the account is taken over and the legitimate owner is logged out.
- Post-compromise monetization — the attacker messages the victim's contacts ("I'm stranded, send money"), joins group chats, harvests contact lists, and uses the trusted identity to phish business partners.
Multiple passkeys plus hardened 2SV attack steps 2 and 3 simultaneously: the attacker needs not just the SMS code but a phishing-resistant credential or a PIN the victim never disclosed. This is a meaningful raise in attacker cost — but only where users have enrolled.
Exploitation status
There is no CVE associated with this news item; this is a platform security-feature release, not a vulnerability disclosure. WhatsApp account-takeover via SIM swapping and SMS-code interception remains actively exploited in the wild as an ongoing criminal technique, not a discrete patchable bug. The defensive value here is configuration and adoption, not patching.
Executive Takeaways
Because this is a platform feature announcement rather than a technical threat with endpoint telemetry, the right response is policy, configuration, and user-hardening guidance rather than detection rules. These are the actions we recommend to clients:
1. Mandate WhatsApp 2SV enrollment for executive and high-risk staff. Treat WhatsApp the way you treat any identity-bearing application in your threat model. Executives, finance staff, HR, and anyone in merger/contract negotiations should be required to set a 2SV PIN, and that requirement should be verified during onboarding and periodic security reviews. The PIN should not be a birthdate, a phone-number fragment, or 123456 — the credential-stuffing equivalent of PIN guessing is real.
2. Drive passkey enrollment as the primary authentication posture. Direct users to register a passkey on each trusted device, and encourage storage of at least one passkey in an enterprise-managed password manager or hardware-backed store where feasible. This gives a recovery path that survives a lost phone and a SIM swap. Document the enrollment steps in your security awareness materials — most users do not know the feature exists.
3. Bind a hardened recovery email to every 2SV configuration. The recovery email should itself be protected by phishing-resistant MFA (FIDO2 security key or passkey, not SMS OTP). A WhatsApp 2SV PIN recoverable via an email account that is itself protected only by SMS simply relocates the same weakness one hop away. Chain-of-trust discipline applies here exactly as it does for your IdP.
4. Attack the root cause: carrier-level SIM-swap protections. Passkeys and 2SV raise the bar, but the underlying exposure is the mobile carrier account. High-risk individuals should have a carrier account PIN/passphrase set, port-out freeze or number-lock enabled where the carrier supports it, and — where available — should be moved to carriers or plans with verified in-person or callback-based port-out procedures. Include carrier hardening in your executive-protection checklist.
5. Build WhatsApp-compromise response into your IR runbook. When an executive's WhatsApp is hijacked, the clock matters: attacker-in-control accounts are used for fraud within hours. Your runbook should cover: contacting WhatsApp support to force re-registration, notifying the compromised account's key contacts through an out-of-band channel, checking linked devices (WhatsApp Web/Desktop sessions persist and are a separate compromise vector), and preserving evidence. Rehearse it — we've seen organizations lose days figuring out who even owns the relationship with Meta support.
6. Audit linked devices and session hygiene. Separately from this rollout: WhatsApp's linked-devices feature means a session on a shared or unmanaged computer can persist after the owner walks away. Periodic review of Settings → Linked Devices should be part of executive device hygiene checks, and any unrecognized session is a potential incident, not a curiosity.
Remediation and Hardening Steps (User- and Org-Level)
- Enable two-step verification: WhatsApp → Settings → Account → Two-step verification → set a strong, non-obvious 6-digit PIN and add a recovery email address.
- Register passkeys on each trusted device: WhatsApp → Settings → Account → Passkeys → create a passkey per device; store at least one in a password manager or hardware-backed credential store.
- Harden the recovery email with FIDO2/security-key MFA; remove SMS as an MFA or recovery factor on that mailbox where the provider allows.
- Carrier controls: set a carrier account PIN, enable port-out freeze/number lock, and document the carrier's social-engineering-resistant verification process for high-risk staff.
- Review linked devices monthly on executive accounts; terminate any session that is not explicitly recognized.
- Update security awareness content to cover WhatsApp registration-code phishing — users must know that WhatsApp verification codes and 2SV PINs are never legitimately requested by anyone, including "WhatsApp support."
- Update your IR runbook with the WhatsApp takeover playbook described above, including out-of-band contact notification templates for fraud attempts launched from a hijacked account.
The Bottom Line
WhatsApp's move to multiple passkeys and stronger two-step verification is a genuinely meaningful control improvement against the registration-hijacking techniques that drive real-world account takeover. But these are opt-in controls. The gap between "feature exists" and "feature enabled on your CEO's phone" is exactly where attackers operate. Security teams should treat this rollout as a trigger for a concrete enrollment and hardening campaign — measured, verified, and folded into executive protection and IR readiness — rather than as a news item to note and move past.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.