Your organization just rolled out passkeys to eliminate phishing. Now attackers are targeting the enrollment process itself.
Since April 2026, the threat actor O-UNC-066 has operated a phishing kit specifically designed to exploit Microsoft 365 passkey registration. They call users directly, impersonate IT support, and walk them through a fake enrollment flow while registering their own passkey in the victim's account. The kit uses a PHP panel with 1-second polling that lets operators adapt the phishing pages in real-time based on what MFA challenges appear.
This isn't a credential replay attack. It's a coordinated vishing scheme that turns your security upgrade into an attack vector.
Why These Mistakes Keep Happening
Passkey adoption is accelerating faster than user education. Microsoft enabled default passkey nudges in May 2026, prompting users to enroll at sign-in. That legitimate security push created the perfect pretext for social engineering.
Security teams often think phishing-resistant authentication solves the phishing problem. It does, for sign-in. But the enrollment ceremony itself becomes the new weak point. If an attacker can convince a user to approve their passkey registration, they've bypassed every downstream control.
The second issue: most organizations treat vishing as a user problem, not an infrastructure problem. You've hardened your authentication policies, but you haven't hardened the enrollment process with the same rigor.
Mistake 1: No Phishing Resistance During Enrollment
Why it happens: You enforce phishing-resistant authentication for application access but don't apply the same standard to authenticator lifecycle events. Adding a new passkey, resetting MFA, or recovering an account often requires only a password and a legacy OTP.
The consequence: An attacker with stolen credentials can register their own FIDO2 authenticator without triggering your adaptive access policies. O-UNC-066's kit captures passwords and OTPs through pages like /submit-otp and /submit-authenticator, then uses those credentials to complete real Microsoft enrollment flows. The victim thinks they're setting up their passkey. The attacker is setting up theirs.
The fix: Apply Okta Account Management Policies (or equivalent controls in your IdP) that require phishing-resistant authentication before any authenticator modification. If a user wants to add a passkey, they should authenticate with an existing passkey, Okta FastPass, or a Multi-Factor Cryptographic Device. Password-plus-OTP isn't sufficient for lifecycle events that grant persistent access.
Mistake 2: Treating Vishing as a Training Problem Alone
Why it happens: Security awareness training tells users "don't click suspicious links" and "verify caller identity." But when a threat actor calls with your organization's branding, references a real passkey campaign your IT team announced last week, and displays a pixel-perfect Microsoft page, user skepticism breaks down.
The consequence: O-UNC-066 registers domains like assignpasskey.com and creates per-target subdomains such as exampleentity.setpasskey.com. They load legitimate Microsoft styling from Microsoft's CDN and pre-stage your organization's logo and background. The phishing kit includes a /processing page that stalls the user while the operator enters stolen credentials at the real Microsoft sign-in page. Users see what looks like a legitimate enrollment flow, complete with branded elements they recognize.
The fix: Establish out-of-band verification protocols for any authenticator enrollment initiated by a phone call. Publish a dedicated IT support number that users can call back to verify requests. Configure your helpdesk ticketing system to create a visible record every time IT contacts a user about MFA changes. If a user receives an unsolicited call about passkey enrollment, they should hang up and initiate contact through a known-good channel.
Mistake 3: No Network-Based Restrictions on Enrollment
Why it happens: You've configured network zones to block sign-ins from high-risk ASNs or geographies, but those policies don't extend to the enrollment process. An attacker operating from DDoS-Guard (AS57724) or IQWeb FZ-LLC (AS59692) can register a passkey as long as they have valid credentials.
The consequence: O-UNC-066's infrastructure is hosted on known bulletproof providers. If your network policies allow passkey enrollment from any location, you're giving attackers the same access your employees have during the most sensitive operation in the identity lifecycle.
The fix: Configure network zones that deny authenticator enrollment from ASNs and countries where your organization doesn't operate. If you don't have employees in Russia, block enrollment requests from Russian IP space. Apply these restrictions at the IdP level, not just at the application layer. For remote workers traveling internationally, provide a documented exception process that requires manager approval and temporary network zone adjustments.
Mistake 4: Relying on User Recognition of Passkey Ceremonies
Why it happens: You assume users will notice when a passkey enrollment doesn't trigger the expected system dialog. O-UNC-066's kit includes a /passkey/register page that mimics the Microsoft enrollment flow without actually invoking the WebAuthn API. It then presents a /passkey page with BIP-39 seed phrases, asking users to "save your recovery key."
The consequence: Users unfamiliar with FIDO2 don't know what a legitimate passkey ceremony looks like. They see Microsoft branding, a progress indicator, and a recovery key prompt. The kit's /passkey/check page even asks them to verify the final word in the seed phrase, creating the illusion of a security measure. Meanwhile, the attacker has already registered their own passkey directly with Microsoft using the stolen session.
The fix: Send end user notifications for every authenticator lifecycle event. When a passkey is registered, the account owner should receive an email or SMS immediately. That notification should include the device name, registration timestamp, and IP address. If the user didn't initiate the enrollment, they can revoke the passkey before the attacker uses it. Configure these alerts as non-dismissible and route them to a secondary communication channel the attacker can't intercept.
Mistake 5: No Device Context in Enrollment Policies
Why it happens: Your authentication policies require managed devices for application access, but you don't enforce the same requirement for passkey enrollment. A user can register a new FIDO2 authenticator from an unmanaged laptop without triggering additional scrutiny.
The consequence: An attacker who compromises credentials through vishing can register their passkey from any device. You've lost the device trust signal that would normally flag suspicious activity. The passkey itself becomes a persistent backdoor, valid until the user manually revokes it or your next Certification Campaign catches the anomaly.
The fix: Restrict authenticator enrollment to managed devices. Use endpoint management signals (MDM enrollment status, security posture, device compliance) as prerequisites for adding new passkeys. If a user needs to enroll from an unmanaged device, require step-up authentication with an existing phishing-resistant factor and manager approval. Log every enrollment attempt that fails device context checks and route those events to your SIEM for correlation with other suspicious activity.
Prevention Checklist
- Require phishing-resistant authentication for all authenticator lifecycle events (add, modify, remove)
- Configure network zones that block enrollment from high-risk ASNs and geographies where you don't operate
- Publish and communicate an out-of-band verification process for IT-initiated enrollment requests
- Enable real-time notifications for every passkey registration, sent to a secondary channel
- Restrict passkey enrollment to managed devices with verified security posture
- Document and test an exception process for legitimate international enrollment scenarios
- Route failed enrollment attempts and anomalous device contexts to your SIEM
- Include vishing scenarios in your incident response playbook with specific passkey revocation procedures
- Review your helpdesk scripts to ensure they never initiate unsolicited passkey enrollment calls
- Audit existing passkeys quarterly for devices and registration timestamps that don't match expected patterns
Passkeys eliminate credential phishing. They don't eliminate social engineering. Treat the enrollment process with the same paranoia you apply to privileged access, because that's exactly what it grants.
