How should security teams manage passkeys and hardware tokens in highly regulated or on-premises environments?

Why This Matters for Security Teams

Passkeys and hardware tokens solve a different problem than passwords: they raise authentication assurance, but they do not automatically solve enrollment, revocation, recovery, or device custody. In highly regulated or on-premises environments, those lifecycle steps matter as much as the authenticator itself. Security teams also need assurance that authenticators can be issued and governed inside the trusted boundary, without relying on external cloud flows that may conflict with data residency, segmentation, or audit requirements.

This is where many programmes underperform. Identity teams often focus on phishing resistance and overlook operational control, yet the biggest failures in practice come from weak registration governance, shared recovery paths, and inconsistent token inventory. NHI Management Group has repeatedly highlighted how lifecycle gaps and secret sprawl drive real exposure in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Guide to the Secret Sprawl Challenge.

Current guidance suggests aligning authenticator choice with local operational constraints, not vendor convenience. The NIST Cybersecurity Framework 2.0 remains useful here because it frames identity as part of broader governance, inventory, and recovery discipline. In practice, many security teams discover token sprawl only after a lost-device event or account recovery incident exposes how weak their real enrollment controls were.

How It Works in Practice

For regulated and on-premises environments, the practical model is to treat passkeys and hardware tokens as managed authenticators with tightly controlled issuance, binding, and recovery. The key question is not simply whether the device is phishing resistant, but whether the organisation can prove who enrolled it, where the key material lives, how long it remains valid, and how it is removed when the user changes role or leaves.

A workable approach usually includes the following:

• Register authenticators inside the enterprise boundary, with administrative approval and audited identity proofing.
• Prefer hardware-backed or device-bound authenticators that support local policy enforcement and offline validation where needed.
• Use centralized lifecycle management so enrollment, suspension, replacement, and revocation are consistent across sites and business units.
• Keep recovery paths stronger than the primary factor, with step-up verification, break-glass approval, and logging.
• Maintain an inventory of all registered authenticators, including ownership, last use, and expiration.

That lifecycle view matters because credential assurance collapses when issuance and revocation are handled inconsistently. The research in The 2025 State of NHIs and Secrets in Cybersecurity shows how often credentials remain active or duplicated beyond their intended use, which is a strong warning for token governance as well. For regulated environments, the better operational pattern is local trust, centralized policy, and short, auditable recovery windows rather than ad hoc self-service resets.

Security teams should also distinguish between user convenience and control-plane sovereignty. If the environment requires offline enrollment, isolated networks, or strict change management, passkey sync features and cloud-mediated recovery may be unacceptable even if they are technically secure. These controls tend to break down when multiple sites, legacy PAM workflows, and inconsistent device standards force exceptions that bypass the approved registration process.

Common Variations and Edge Cases

Tighter authenticator control often increases onboarding friction and help desk load, requiring organisations to balance phishing resistance against operational continuity. That tradeoff is especially visible in air-gapped, unionized, or safety-critical environments where user lockout can have real business impact. The goal is not maximum restriction at all times, but predictable governance with clear exceptions.

One common edge case is shared workstations or kiosk-style access. In those settings, passkeys may be inappropriate if device possession cannot be reliably tied to a single person. Another is disaster recovery: organisations sometimes depend on cloud account recovery or external sync because it is convenient, but best practice is evolving toward locally governed recovery that preserves the same assurance level as normal authentication. There is no universal standard for this yet, so policy should be explicit about what counts as acceptable fallback.

Hardware tokens also need a replacement strategy. Lost, damaged, or expired devices should be reissued through a tracked process, not informally swapped by local admins. Where offline environments are involved, the strongest pattern is often a tiered model: primary hardware token, secondary locally issued backup, and privileged break-glass access with additional approvals. That helps preserve continuity without silently weakening identity assurance.

For organisations mapping these controls to governance programmes, the NIST Cybersecurity Framework 2.0 is still the cleanest way to tie authenticator management to asset inventory, access control, and recovery discipline. In regulated operations, the hardest failures usually come from exception handling, not the authenticators themselves.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams run AI pentesting in highly regulated environments without exposing source code or prompts?
• How should security teams build audit-ready password governance reporting across hybrid environments?