As passkeys and phishing-resistant authentication reduce password risk, attackers will move pressure to the recovery plane.
The industry is moving in the right direction.
Passkeys, FIDO2/WebAuthn, hardware security keys, conditional access, better MFA policies, and risk-based sign-in controls are all meaningful improvements. They reduce entire classes of credential theft. They make phishing harder. They remove reusable passwords from many authentication ceremonies. They shift more of the security burden from user judgment to protocol design.
That is good.
But it is not the finish line.
In my recent passkeys article, I called out a point that deserves its own treatment: passkeys do not solve weak account recovery, help desk social engineering, stolen session tokens, OAuth consent abuse, unmanaged vendor access, or excessive privilege. They are a major step forward, but they do not remove the rest of the identity attack surface.
That matters because attackers adapt.
If passwords become harder to steal, guess, spray, reuse, or phish, attackers will apply pressure somewhere else. They will go where the assurance is weaker, the workflows are more manual, the exceptions are more frequent, and the blast radius is still large.
Increasingly, that place is account recovery.
The Inversion Test
A useful way to think about this is inversion.
Do not start with the defender’s roadmap. Start with the attacker’s question:
Once passwords disappear, where would I attack next?
The answer is usually not exotic.
I would attack the process that lets a user back into the account after they lose the device.
I would attack the support workflow that removes an authenticator.
I would attack the exception path that grants temporary access.
I would attack the SaaS admin who can approve OAuth grants.
I would attack the vendor portal that still uses email-based recovery.
I would steal a browser session instead of a password.
I would enroll a new device.
I would persuade the help desk to do for me what the authentication system will not.
That is the problem.
Authentication is getting stronger, but recovery is often still treated like customer service, not like privileged access.
The Recovery Plane Is Bigger Than Password Reset
When many teams hear “account recovery,” they think about password reset.
That definition is too narrow.
The recovery plane includes every path that can restore, replace, bypass, reset, re-enroll, approve, or extend access after normal authentication fails or becomes inconvenient.
That includes:
- Password reset and account unlock workflows
- MFA reset
- Authenticator removal
- Passkey re-enrollment
- Lost phone and device replacement processes
- Temporary access passes
- Emergency access procedures
- Help desk verification scripts
- Vendor support portals
- OAuth consent grants
- Long-lived sessions
- Break-glass accounts
- Shared accounts
- Offboarding workflows
That is a lot of surface area.
It is also where many organizations have the least visibility.
They can tell you how many users enrolled a passkey. They can tell you how many privileged users have hardware keys. They can show a nice adoption dashboard.
But ask how many privileged recovery events occurred last quarter, how many required human exception, how often callbacks used known-good numbers, how many OAuth grants have offline access, or how many vendor admins can recover access without the organization’s IdP, and the room gets quieter.
That is not because security teams do not care.
It is because the measurements have not caught up to the new risk.
Passkey Adoption Is Not the Same as Recovery Risk Reduction
Most passkey programs measure adoption.
That is understandable. Adoption matters. A phishing-resistant authenticator that nobody uses is not a control; it is a feature sitting idle.
But adoption alone can become a vanity metric.
A dashboard that says “82% of users have enrolled passkeys” may look good while the recovery plane remains weak. A privileged administrator may have a hardware key and still be vulnerable if a support agent can remove that key after a convincing phone call. A finance user may authenticate with a passkey and still have an OAuth grant that allows a third-party application to read mail and files. A SaaS admin may have phishing-resistant login and still carry a session token that can be replayed from an infected endpoint.
In other words, the front door can improve while the side doors remain unchanged.
The right question is not only:
How many users have passkeys?
The better question is:
Can an attacker still recover, re-enroll, delegate, or persist access without satisfying the same level of assurance we require at login?
That question changes the program.
Why Attackers Like Recovery Paths
Recovery paths are attractive because they are designed for failure.
Users lose phones. Laptops die. Executives travel. Hardware keys get left at home. Contractors change devices. Mergers bring strange identity histories. Help desks are measured on resolution time. Business units want access restored now. Support teams are asked to be helpful, empathetic, and fast.
Attackers understand this.
They do not need to defeat your strongest control if they can trigger a workflow that temporarily removes it. They do not need a zero-day if they can convince a support agent that the CFO is locked out before payroll closes. They do not need to phish a password if a malicious OAuth application can be granted the right permissions. They do not need to reauthenticate if a stolen session or refresh token remains valid.
This is second-order identity risk.
The first-order improvement is passwordless authentication.
The second-order attacker response is pressure on the lifecycle around authentication.
That is where many programs are underbuilt.
Help Desks Are Now Part of the Identity Control Plane
Help desk directors should be in the room for passkey planning.
Not after rollout.
Before rollout.
The support function is no longer just a service channel. In a passwordless environment, it becomes one of the places where identity assurance is either preserved or quietly downgraded.
When a support agent removes an authenticator, issues a temporary access pass, resets MFA, unlocks an account, updates a phone number, or approves device replacement, that agent may be changing the effective security posture of the identity.
For normal users, that can still matter.
For privileged users, it can be catastrophic.
Scattered Spider is a useful warning here. CISA has described the group’s use of social engineering to convince IT help desk personnel to reset passwords and MFA tokens, and CISA’s mitigation guidance emphasizes phishing-resistant MFA such as FIDO/WebAuthn.
The broader lesson is that support and recovery workflows can become identity attack paths when attackers cannot easily defeat the primary login ceremony.
The lesson is simple: recovery for privileged users should not be a normal ticket.
It should be a controlled ceremony.
That means strong proofing, out-of-band verification using known-good contact information, two-person approval, time-bound access, explicit logging, alerting to security operations, and post-event review.
It also means the help desk needs permission to slow down when risk is high.
“Fast resolution” cannot be the only service metric when the request changes identity assurance.
Fallback Methods Are the Old Attack Surface Wearing a New Name
Fallback methods are often kept for good reasons.
They reduce lockouts. They make pilots easier. They help executives. They make support less painful. They allow legacy applications to keep working. They reduce friction for BYOD and remote users.
But they also preserve the attack surface that passkeys were meant to reduce.
SMS, voice OTP, email OTP, TOTP, push approval, security questions, personal email recovery, and “call the help desk” workflows can become the weakest link in an otherwise strong authentication program.
That does not mean every fallback disappears on day one.
It means fallback must be governed by risk tier, not convenience.
For privileged users, weak fallback should be removed first.
For high-risk business users, fallback should be limited, logged, and reviewed.
For standard users, fallback should be transitional and measured.
For vendors, fallback should be part of the access contract.
For break-glass accounts, fallback should be designed, vaulted, monitored, and tested.
Do not let fallback become the permanent exception nobody owns.
Device Replacement Is a Security Event
Passkeys change the device lifecycle.
If the authenticator is a phone, laptop, platform credential, password manager, sync fabric, or hardware key, then device loss and device replacement become security-sensitive workflows.
A new phone is not just a new phone.
It may be the path to a new authenticator.
A laptop rebuild is not just an endpoint ticket.
It may become a passkey re-enrollment event.
A password manager recovery is not just a user convenience problem.
It may restore access to synced credentials.
NIST’s current SP 800-63B language draws an important assurance distinction here: syncable authenticators are not allowed at AAL3 because syncing requires the private key to be exportable, while AAL3 requires stronger hardware-protected key handling.
That distinction should shape enterprise recovery design.
The organization should know which authenticators are allowed for which risk tiers, whether credentials are synced or device-bound, how many authenticators each user must maintain, what happens when one is lost, and who can approve replacement.
For high-risk roles, device replacement should trigger stronger checks than normal sign-in.
If the attacker’s goal is to become the new device, then treating new-device enrollment as routine is a mistake.
OAuth Grants Are Recovery’s Cousin
OAuth consent is not account recovery in the traditional sense, but it belongs in the same risk conversation.
Why?
Because OAuth grants can create durable delegated access that survives the user’s normal login ceremony. In many attacks, the adversary does not need the password. The user is tricked into granting a malicious or compromised application access to mail, files, contacts, or other SaaS data. The attacker then operates through authorized application access rather than a classic interactive login.
Microsoft describes consent phishing as an attack where users are tricked into granting permissions to malicious cloud applications, allowing those applications to access legitimate cloud services and user data. Microsoft also recommends auditing applications and consented permissions, limiting user consent, and monitoring suspicious application behavior.
Red Canary describes application access token theft as a technique adversaries use to gain unauthorized access to SaaS, cloud, and containerized resources, including through OAuth consent grant attacks.
That is an identity bypass from a governance point of view.
If your passkey program does not include connected-app review, admin consent workflows, publisher verification, permission classification, and revocation procedures, then you have left a major identity path out of scope.
This is especially important in Microsoft 365, Google Workspace, Salesforce, GitHub, Slack, Box, Dropbox, and other SaaS-heavy environments where business productivity depends on integrations.
Security teams should ask:
- Who can consent to applications?
- Which grants include mail, files, directory, impersonation, or offline access?
- Which applications are publisher verified?
- Which grants are unused, stale, or excessive?
- Which service principals have tenant-wide reach?
- How quickly can suspicious consent be revoked?
- Are OAuth changes visible in the SIEM?
Do not celebrate passwordless authentication while ignoring delegated access.
Sessions Are Where Authentication Becomes Authorization
Another uncomfortable point: authentication strength does not automatically protect the entire session.
After authentication succeeds, applications issue session tokens, cookies, and refresh tokens. Those artifacts often become the practical proof that the user is already trusted. If malware, a phishing proxy, browser compromise, or endpoint theft captures that token, the attacker may be able to bypass the login ceremony entirely.
Ping Identity describes session hijacking as reuse of a stolen session token to impersonate a logged-in user; because the attack occurs after login, MFA may already be satisfied.
Microsoft has also published guidance on cloud token theft, including prevention, detection, and response considerations for token-based attacks.
That is why session governance belongs in the passkey roadmap.
Shorter session lifetimes, device compliance, token binding where available, continuous access evaluation, impossible travel detection, user-agent and device mismatch analytics, rapid revocation, EDR coverage, browser hardening, and SaaS session visibility all matter.
Passkeys reduce credential theft.
They do not make stolen sessions harmless.
A Recovery-Plane Risk Score
Organizations need a way to score recovery paths the same way they score applications, data, vendors, and vulnerabilities.
Here is a practical model.
| Factor | Question | High-Risk Signal |
|---|---|---|
| Proof strength | How strongly does the process verify the person requesting recovery? | Email access, caller ID, personal information, or manager approval alone. |
| Social-engineering exposure | Can a human be pressured into overriding controls? | Phone-only recovery, urgent executive exceptions, vague escalation rules. |
| Exception frequency | How often is the standard process bypassed? | Frequent temporary access, recurring VIP exceptions, non-expiring risk acceptances. |
| Blast radius | What can the recovered account access? | Admin roles, finance workflows, HR data, developer systems, mailboxes, cloud consoles. |
| Persistence | Does recovery create long-lived access? | Refresh tokens, remembered devices, OAuth grants, persistent sessions, new authenticators. |
| Visibility | Can security see and investigate the event? | No SIEM logging, no alerting, limited ticket context, SaaS-only logs. |
| Ownership | Who governs the path? | No control owner, no review cadence, split responsibility between IAM and support. |
Score each recovery path from 1 to 5 on each factor.
Then multiply or weight by user tier.
A recovery path for a standard user with limited SaaS access is not the same as a recovery path for a global admin, payroll approver, domain admin, developer with production access, or vendor administrator.
Do not flatten the organization.
Risk is not evenly distributed. Recovery controls should not be either.
What Leaders Should Measure
CISOs and IAM leaders should add recovery-plane metrics to identity dashboards.
At minimum, track:
- Recovery events by user tier
- Authenticator resets and removals
- New authenticator enrollments
- Temporary access passes
- Privileged recovery exceptions
- Help desk recovery requests denied or escalated
- Recovery events outside business hours
- Users with fewer than two approved authenticators
- Weak fallback still enabled by tier
- OAuth grants by risk level
- Long-lived session exceptions
- Third-party accounts without phishing-resistant authentication
- Vendor support paths that bypass the primary IdP
- Open recovery exceptions by owner and expiration date
The executive dashboard should answer a plain question:
Can someone get back into a high-risk account through a process weaker than the process required to sign in?
If the answer is yes, the organization has work to do.
A Practical 90-Day Plan
Days 0–30: Inventory the Recovery Plane
Start with the systems that matter most:
- IdP
- Endpoint management
- PAM
- Cloud consoles
- Finance systems
- HR systems
- Developer platforms
- Backup consoles
- EDR
- SIEM
- Ticketing
- Major SaaS applications
For each system, document:
- Normal authentication method
- Recovery method
- Fallback methods
- Approval path
- Required proof
- Generated logs
- Alerts
- Temporary access lifetime
- Post-recovery review process
Do not start by buying another tool.
Start by finding the paths.
Days 31–60: Harden High-Risk Recovery
Prioritize administrators, executives, finance, HR, developers, help desk staff, security staff, and third parties with privileged or sensitive access.
For those users:
- Require at least two approved authenticators before enforcement.
- Remove weak fallback where feasible.
- Require device-bound passkeys or hardware keys for privileged access.
- Implement two-person approval for privileged authenticator reset.
- Use known-good callback procedures.
- Alert on authenticator removal and re-enrollment.
- Require post-recovery review for high-risk accounts.
This is also the time to train the help desk on adversarial recovery scenarios.
Not generic security awareness.
Specific scripts.
Specific red flags.
Specific escalation authority.
The help desk needs to know when a request is no longer just a request.
It is a security event.
Days 61–90: Govern Tokens, Grants, Vendors, and Exceptions
Once the human recovery paths are under control, expand to adjacent identity persistence.
Review OAuth grants and connected applications.
Restrict user consent for higher-risk permissions.
Implement admin consent workflows.
Review refresh token and session lifetime policies.
Test rapid session revocation.
Identify vendor-controlled recovery paths.
Require phishing-resistant MFA for vendors with privileged access.
Publish an exception register with owners and expiration dates.
Run a tabletop exercise against recovery abuse.
The tabletop should be blunt:
An attacker has convinced the help desk to remove MFA from a finance administrator. What alerts fire? Who knows? How fast can we revoke sessions, disable OAuth grants, suspend the account, preserve evidence, and determine blast radius?
If that exercise feels uncomfortable, good.
That is the point.
Policy Baseline Language
Here is practical language to adapt:
Account recovery, authenticator reset, passkey registration, passkey removal, device replacement, temporary access issuance, OAuth consent approval, and session revocation are security-sensitive identity lifecycle events. These events must be governed by risk tier, verified using approved proofing methods, logged centrally, monitored for abuse, and reviewed for privileged or high-impact users. Recovery processes must not allow access to be restored through a weaker assurance path than the access being recovered without documented, time-bound risk acceptance.
That last sentence is the core principle.
Do not let recovery be weaker than login.
Where Compliance and Risk Teams Fit
Compliance teams should pay attention because recovery-plane risk creates evidence problems.
When auditors ask whether privileged access is controlled, the answer cannot stop at:
We require MFA.
The next questions are predictable:
- How is MFA reset?
- Who can approve a reset?
- Are approvals logged?
- Can support staff bypass the policy?
- Are exceptions time-bound?
- Are recovery events reviewed?
- Are vendor recovery paths included?
- Are OAuth grants reviewed?
- Can sessions be revoked?
Those are not theoretical questions.
They are control design questions.
They are also incident response questions.
A mature identity program should be able to produce evidence for recovery events the same way it produces evidence for access reviews, privileged access approvals, and policy exceptions.
The Bottom Line
Passkeys are a real improvement.
Phishing-resistant authentication is worth doing.
Hardware keys for privileged users are worth the operational effort.
Conditional access, MFA cleanup, passkey rollout roadmaps, and fallback reduction all matter.
But the next identity fight is not only at login.
It is in recovery.
It is in help desk workflows.
It is in device replacement.
It is in OAuth consent.
It is in session persistence.
It is in vendor support paths.
It is in the exception process.
Attackers follow pressure. As the password attack surface shrinks, the recovery attack surface becomes more valuable.
So build for that reality now.
Measure recovery-plane risk.
Score recovery paths by proof strength, social-engineering exposure, exception frequency, persistence, visibility, ownership, and blast radius.
Harden the workflows that can restore high-impact access.
Give the help desk better procedures and the authority to use them.
Govern OAuth and sessions as part of identity, not as unrelated SaaS hygiene.
Treat vendor access and support recovery as part of the enterprise control plane.
The goal is not to make recovery impossible.
People will lose devices. Executives will travel. Hardware will fail. Business will need continuity.
The goal is to make recovery trustworthy.
Because in a passwordless world, the attacker does not need your password if they can become your recovery event.
More Information and Assistance
At MicroSolved, Inc., we help organizations move from security intentions to operational reality. If you are rolling out passkeys, hardening MFA, modernizing IAM, or trying to understand whether your recovery plane is becoming your weakest identity control, we can help.
MicroSolved can assist with:
- Identity architecture assessments
- Passkey and phishing-resistant authentication roadmaps
- Account recovery and help desk workflow hardening
- OAuth grant and SaaS identity reviews
- Privileged access and vendor access risk reduction
- Identity logging and SIEM use-case development
- Tabletop exercises and adversarial simulations focused on recovery abuse
- Executive dashboards for identity risk reduction
Contact MicroSolved at +1.614.351.1237 or info@microsolved.com.
Relax. We’re on watch.
* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.
Understanding how passkeys function illuminates their potential to become the linchpin of corporate security. With benefits ranging from reducing phishing to simplifying the login process, passkeys present an enticing alternative to traditional passwords. This article offers an insight into the realm of passkeys, their synergy with multi-factor authentication, and the intriguing possibility of facial recognition as a passkey.