Organisations should combine centralized policy control with end-user self-service for ordering and delivery. IT keeps governance over eligibility, inventory, and roles, while employees complete address and device selection within approved workflows. This reduces help desk load, speeds adoption, and preserves control over who receives which credentials and where they are shipped.
Why This Matters for Security Teams
Phishing-resistant hardware passkeys solve a real authentication problem, but the rollout often fails on operations, not cryptography. If IT becomes the bottleneck for ordering, shipping, replacement, and recovery, adoption slows and users work around policy. That creates the same shadow access problems organisations were trying to remove, only with better branding. NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that identity controls need governance, accountability, and lifecycle discipline, not just stronger authenticators.
NHI Management Group has repeatedly shown how identity failures compound when ownership, inventory, and revocation are unclear. Its analysis of the Ultimate Guide to NHIs underscores that poor lifecycle control is a systemic issue, not a niche admin problem. The same pattern appears in phishing-resistant hardware passkey programmes: the technology is sound, but the rollout breaks when service desks are asked to manually process every exception, address change, and device request. In practice, many security teams encounter passkey resistance only after ticket volume spikes and users start delaying enrolment rather than through intentional rollout design.
How It Works in Practice
The most scalable model is central governance with delegated execution. Security and identity teams define who is eligible for a hardware passkey, what models are approved, where devices may be shipped, and which assurance checks are required. Employees then complete the low-risk parts of the process through self-service, such as confirming delivery details, selecting an approved device type, or initiating replacement within policy boundaries. This reduces friction without surrendering control.
Operationally, the workflow should separate policy from fulfilment:
- IT approves eligibility rules by role, risk tier, or device posture.
- Users self-serve address confirmation and device preference inside an approved catalog.
- Shipping and inventory are tracked centrally to preserve auditability.
- Lost, stolen, or damaged hardware triggers a time-bound recovery path and revocation of the old credential.
- Exceptions route to human approval only when the request falls outside policy.
This is where phishing-resistant authentication differs from older MFA approaches. The goal is not just stronger login, but lower reliance on help desk intervention at the exact moment an organisation is trying to improve security. Controls should be designed so that one passkey lifecycle event does not require a manual ticket, a manager approval, and a security review unless the risk level truly warrants it. NIST guidance on identity assurance and access control supports that separation of duties, and NHI Management Group’s research on CoPhish OAuth Token Theft via Copilot Studio and the Poland Military Breach show how identity workflows fail when trust is granted too broadly or lifecycle controls are weak. These controls tend to break down in distributed or contractor-heavy environments because shipping, device recovery, and exception handling become inconsistent across regions.
Common Variations and Edge Cases
Tighter passkey governance often increases operational overhead at the start, requiring organisations to balance faster adoption against inventory, shipping, and support constraints. That tradeoff is real, especially when different business units have different device standards or regulatory constraints.
Current guidance suggests a few common variants. Some organisations pre-provision hardware passkeys only for high-risk roles, such as finance, executives, and admins, while others issue them broadly but reserve manual approval for cross-border shipping or privileged users. There is no universal standard for the best recovery model yet, but best practice is evolving toward short-lived recovery workflows, strong identity proofing, and immediate revocation of the old credential before replacement is activated. For shared endpoints, kiosk access, or frontline workers, the rollout may need a separate onboarding path because standard laptop-centric self-service does not fit every population.
Edge cases also matter for IT load. Lost devices, remote employees, and mergers can overwhelm a central desk if exceptions are not designed up front. Organisations should treat passkey rollout as an identity operations programme, not a one-time hardware issue. The practical test is whether an employee can enrol, replace, and recover with minimal support while policy still prevents unauthorised receipt or activation of the device.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle and rotation discipline maps to passkey issuance, replacement, and revocation. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access governance are central to passkey eligibility and enrolment. |
| NIST SP 800-63 | AAL2 | Hardware passkeys are a phishing-resistant authenticator pattern aligned to assurance levels. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust supports continuous verification instead of relying on one-time enrolment. |
| NIST AI RMF | Governance and accountability are needed where automated identity workflows create operational risk. |
Define passkey lifecycle triggers and enforce revocation when devices are lost, replaced, or reassigned.
Related resources from NHI Mgmt Group
- How should security teams roll out passkeys without breaking account recovery?
- How should organisations roll out passkeys without breaking existing login flows?
- How should organisations roll out passkeys without breaking customer login flows?
- How should security teams roll out passkeys without creating support problems?
