Who should approve a new passkey when an employee loses a device?

A new passkey should be approved only through a controlled recovery process with clear accountability, not ad hoc help desk discretion. The approver may be an admin, IT, or a verified identity workflow, but the key requirement is independent proof that the requester is legitimate. Strong programmes use multiple factors, in-person verification, or recovery codes issued at enrollment.

Why This Matters for Security Teams

Passkey recovery is not a routine password reset. It is an identity re-issuance decision that can either preserve phishing resistance or create a high-trust bypass around it. If the wrong person approves a new passkey after a device loss, an attacker can convert a stolen phone, a compromised help desk case, or a rushed exception into durable account takeover. The approval question matters because the recovery path often becomes the weakest link in an otherwise strong authentication programme.

Security teams should treat passkey recovery as a controlled assurance event with independent verification, documented approval, and clear rollback options. That is consistent with the broader identity lessons in the Ultimate Guide to NHIs, which shows how weak lifecycle controls and excessive trust create outsized exposure. The same operational pattern appears in human identity recovery: convenience pressure tends to outpace verification discipline. Current guidance from the NIST Cybersecurity Framework 2.0 supports stronger identity assurance and governed recovery, not informal approval by whoever is available.

In practice, many security teams encounter passkey abuse only after a lost-device request has already become an account compromise, rather than through intentional recovery design.

How It Works in Practice

The approver should be the person or workflow that can independently verify the requester’s identity, not merely the one who receives the ticket. In mature programmes, that means a controlled recovery path with separation of duties: the help desk can initiate the case, but approval comes from a verified identity process, an admin operating under policy, or a second channel that confirms the employee is legitimate.

Good recovery designs usually combine multiple safeguards:

• Pre-enrolled recovery methods such as backup codes or trusted devices
• In-person or live video verification for high-risk accounts
• Manager or HR confirmation only as a supporting signal, not the sole proof
• Temporary step-up checks before the new passkey is bound to the account
• Immediate revocation of the lost device’s authentication session and any related tokens

This is where passkeys differ from simple password resets. A passkey replacement should re-establish proof of possession and proof of continuity, especially if the account protects finance, admin, or privileged access. The least risky pattern is to require the requester to authenticate through an alternate, previously trusted factor before issuance, then log the approver, reason, and evidence chain for audit. That fits the lifecycle emphasis in NHI lifecycle governance guidance, even though the identity type is human.

These controls tend to break down when recovery is routed through outsourced support desks with inconsistent scripts and no reliable verification channel, because speed incentives overwhelm assurance checks.

Common Variations and Edge Cases

Tighter recovery controls often increase user friction and support cost, requiring organisations to balance phishing resistance against downtime and executive pressure. That tradeoff is real, especially for frontline staff, travellers, or employees who lose both the device and their backup method.

There is no universal standard for this yet, but current guidance suggests the approver should vary by risk tier. For low-risk users, a documented identity workflow may be sufficient. For privileged users, finance roles, or executives, the approver should be a higher-assurance function with stronger evidence requirements and stricter logging. In some organisations, the correct approver is not a human at all, but an automated policy gate that checks recovery prerequisites before a human can complete the change.

Edge cases also matter when the device loss coincides with travel, suspected theft, or a recent phishing incident. In those situations, the safer choice is to suspend authentication, not accelerate recovery. If the employee has no recovery codes, no trusted device, and no independent verifier, the answer should be delay until verification is complete, even if that inconveniences the business. NIST’s identity guidance and the broader NHI risk data in the Ultimate Guide to NHIs both point to the same operational truth: weak fallback paths become the real attack surface.

Related resources from NHI Mgmt Group

• What should organisations do when an employee loses a passkey device?
• Who should be accountable for access when an employee transfers to a new team?
• What breaks when session cookies are stolen from a compromised employee device?
• Who should approve creation and permission grants for a new agent identity?