Who is accountable for phishing-resistant authentication rollout when end users can self-order hardware keys?

IT and identity teams remain accountable for governance, eligibility, and control design even when users can self-order devices. Self-service changes the delivery model, not the security responsibility. Organisations still need approval rules, inventory oversight, role assignment, and shipping controls so the process stays auditable and aligned to policy.

Why This Matters for Security Teams

When end users can self-order phishing-resistant hardware keys, the control problem shifts from issuing a device to governing who is eligible, how approval happens, and whether the identity system can still prove the right person received the right authenticator. That matters because rollout errors rarely show up as obvious outages. They show up as weak exceptions, over-broad approvals, and unaudited exceptions that quietly undermine MFA assurance.

Security teams should treat this as a governance and accountability question, not a user convenience feature. NIST SP 800-53 Rev. 5 makes access control, auditability, and identity proofing separate control concerns, and ISO/IEC 27001:2022 expects organisations to assign responsibility and maintain oversight for security processes. In practice, the same pattern that enables fast adoption can also bypass the very checks that make phishing-resistant authentication meaningful. NHI Mgmt Group has repeatedly highlighted how control gaps around identity and secrets become operational risk, including in the Ultimate Guide to NHIs and incident analyses such as CoPhish OAuth Token Theft via Copilot Studio.

In practice, many security teams discover ownership gaps only after an unapproved key is issued, not through a deliberate review of the ordering workflow.

How It Works in Practice

Accountability should stay with IT and identity governance, even if procurement or the end user initiates the order. The business can own the request, but security owns the policy. That means defining who can order a key, what proof is required, which roles are eligible, how replacements are handled, and when exceptions need manual review. The accountable team should also decide whether self-service applies to all staff or only to segments with lower fraud exposure.

A workable process usually includes:

• Eligibility rules tied to role, risk tier, and device posture.
• Approval logic for first issue, replacement, lost device, and overseas shipping.
• Inventory tracking with serial-number binding to the user or account.
• Shipping controls to prevent diversion, reshipment abuse, or address changes.
• Audit logs that show who ordered, who approved, who fulfilled, and when the key became active.

The security model should also preserve phishing resistance after issuance. If the order flow allows unverified identity changes, address changes, or self-approval, the deployment becomes a distribution channel for compromise rather than a control. NIST guidance on strong authentication and logging, together with operating practices documented in the Ultimate Guide to NHIs, reinforces that governance must cover the whole lifecycle, not just enrollment. Where possible, link issuance to a managed identity source and require re-authentication for sensitive actions such as replacement or recovery. These controls tend to break down when shipping is outsourced across regions because fulfilment teams and identity teams lose synchronized visibility into exceptions.

Common Variations and Edge Cases

Tighter self-service often increases operational overhead, requiring organisations to balance user speed against fraud resistance and support burden. That tradeoff becomes sharper for executives, contractors, and remote staff, where one-size-fits-all workflows can either over-restrict access or create weak exception paths. Current guidance suggests that high-risk populations should not use the same frictionless order flow as low-risk employees.

There is also no universal standard for this yet, but best practice is evolving toward tiered issuance. For example, lost-key replacement may require stronger proof than first-time enrollment, and privileged users may need manual approval even if standard users do not. Organisations should also consider whether the self-order portal is itself protected by phishing-resistant authentication, because a weak recovery step can defeat the whole program. The Poland Military Breach is a reminder that identity process weaknesses can have consequences far beyond convenience, especially when control ownership is unclear.

Where the model often fails is in federated or outsourced environments, because no single team owns the complete chain from eligibility decision to physical delivery to activation. In those cases, accountability must be named in policy, not assumed by the tooling.

Related resources from NHI Mgmt Group

• How should government agencies implement phishing-resistant authentication without creating procurement bottlenecks?
• How should organisations roll out phishing-resistant hardware passkeys without overloading IT teams?
• How should security teams govern phishing-resistant authentication for privileged users?
• Who is accountable when phishing-resistant authentication is inconsistent across systems?