You've spent the last year rolling out passkeys, FIDO2 security keys, and Okta FastPass to your workforce. Your authentication policy blocks credential phishing cold. Users can't share secrets they don't possess.
Then an attacker calls your finance director, poses as IT, and walks them through enrolling a passkey, the attacker's passkey, into the user's account. No credentials stolen. No replay attack. Just a phone call and a policy gap you didn't know existed.
These myths about phishing-resistant authentication persist because many IAM teams focus policy enforcement on the authentication moment and treat enrollment as a separate, less-critical workflow. Threat actors have noticed.
Myth 1: Phishing-resistant authentication protects the entire identity lifecycle
Reality: Phishing resistance applies only where you enforce it in policy. If your authentication policy requires FIDO2 but your account management policy allows users to enroll new authenticators after answering a Time-Based One-Time Password challenge, you've built a reinforced front door with a screen door around back.
Over the last 12 months, Okta Threat Intelligence observed multiple threat actor clusters pivot from credential phishing to targeting enrollment and recovery flows directly. One in five proactive threat notifications Okta sent to customers in the last month involved phishing domains containing the string "passkey." The threat actor O-UNC-066 impersonates IT teams on voice calls, uses stolen credentials to trigger enrollment, then socially engineers targets into approving attacker-controlled passkey registrations.
The attack succeeds not because passkeys are weak, but because the policy governing who can enroll them and under what conditions remains weaker than the policy governing their use.
Myth 2: Self-service password reset is a convenience feature, not an attack surface
Reality: Self-service password reset (SSPR) is a privileged operation that changes account state. Treat it accordingly.
The threat actor O-UNC-067, active since at least June 2024, performs reconnaissance to identify organizations with SSPR enabled on public sign-in pages. They assess which Multi-Factor Authentication challenges apply during the reset flow, then call targets while simultaneously triggering the password reset. If the policy allows identity verification via push notifications or One-Time Passwords, the attacker talks the user through approving the reset in real time.
This actor doesn't use credential phishing kits at all. They exploit the fact that most organizations apply stricter policy to authentication than to recovery. If your SSPR flow accepts any enrolled factor for verification and permits requests from any IP address, you've created a social engineering shortcut that bypasses your phishing-resistant authentication policy entirely.
Myth 3: Requiring two factors during enrollment is sufficient protection
Reality: Factor count matters less than factor quality and context. An attacker on the phone with a target can guide them through satisfying two weak challenges just as easily as one.
During account recovery or enrollment, many policies present users with a menu of verification options: SMS, email, push notification, TOTP. The user, or the attacker impersonating IT support, picks the weakest, most "phishable" method. Requiring two challenges from that menu doesn't materially increase resistance if both challenges are susceptible to social engineering.
Account Management Policies in Okta allow you to require phishing-resistant verification (FIDO2, Okta FastPass, smart cards) before any authenticator can be added or modified. This applies the same rigor to lifecycle events that you've already applied to authentication. The policy can also restrict enrollment requests to managed devices or trusted IP ranges, adding contextual controls that pure factor-count requirements can't provide.
Myth 4: Helpdesk-assisted recovery is more secure than self-service
Reality: Helpdesk recovery is only as secure as your helpdesk's verification process, and attackers are impersonating helpdesk staff in both directions.
Threat actors impersonate IT support to users (O-UNC-025, O-UNC-028, O-UNC-045, O-UNC-053, O-UNC-066). They also impersonate users to helpdesks, exploiting weak identity proofing to request resets. If your helpdesk verifies identity by asking for information an attacker could obtain through reconnaissance or prior compromise, employee ID, manager name, last four digits of SSN, you're relying on knowledge-based authentication in an era when knowledge is commoditized.
The strongest recovery posture eliminates the need for most helpdesk interventions by enrolling users in multiple phishing-resistant authenticators across separate devices. If a user enrolls Okta Verify on both their laptop and smartphone, plus a hardware security key, losing one device doesn't trigger a recovery event. They use a remaining phishing-resistant factor to enroll the replacement device.
When helpdesk recovery is unavoidable, integrate identity verification services that require government-issued ID and liveness checks. This raises the bar beyond what a voice call can achieve.
Myth 5: We'll strengthen enrollment policies after we finish the passkey rollout
Reality: Attackers are already targeting your enrollment flow. One in five recent Okta threat notifications involved passkey-themed phishing. Delaying policy hardening gives threat actors a window to establish persistence before you close it.
The strongest immediate step: configure Account Management Policies so the top rule requires phishing-resistant verification and managed device context before any factor can be added or modified. Users who don't yet meet those criteria fall through to lower rules with temporary accommodations (trusted network requirement, identity verification challenge, limited time window for onboarding). Use event hooks or Okta Workflows to automatically promote users into the strictest policy group as they enroll sufficient phishing-resistant factors.
Always end the policy stack with an explicit deny rule to catch unintended scenarios.
What to do instead
Stop treating enrollment and recovery as secondary workflows. Apply the same zero-trust rigor to account management that you apply to authentication:
Require phishing-resistant verification for all authenticator lifecycle events. Use Account Management Policies to enforce FIDO2, Okta FastPass, or smart card challenges before users can add, modify, or recover authenticators.
Enroll users in multiple phishing-resistant factors across separate devices. This eliminates most recovery scenarios. A user with Okta Verify on a laptop and phone doesn't need helpdesk intervention when one device fails.
Remove SSPR links from public sign-in pages for workforce users. Move recovery operations behind authenticated settings or restrict access to trusted networks using Okta network zones.
Restrict enrollment requests by device and network context. Require managed devices and known IP ranges for lifecycle operations, especially during onboarding windows.
Integrate identity verification services for edge cases. When phishing-resistant recovery isn't possible, require government ID and liveness checks rather than knowledge-based authentication.
Phishing-resistant authentication works. But if your enrollment policy still accepts a push notification as proof of identity, you're securing the vault while leaving the key-cutting machine unattended.
