By NHI Mgmt Group Editorial TeamDomain: Governance & RiskSource: YubicoPublished December 11, 2025

TL;DR: The DoW CIO’s new MFA memo approves device-bound FIDO2 passkeys on YubiKeys for DoD use cases, clarifies DoD PKI as the primary credential, and expands guidance across shared devices, BYO mobile, and privileged access scenarios, according to Yubico. The policy shift matters because it removes ambiguity around passwordless authentication, but identity teams still need to map use cases, credential lifecycle, and device-bound assurance to their own governance model.


At a glance

What this is: The DoD MFA memo approves device-bound FIDO2 passkeys on YubiKeys and clarifies where they fit across DoD authentication use cases.

Why it matters: IAM and PAM teams should treat this as a policy signal that phishing-resistant, device-bound authentication is moving into broader operational use, with implications for credential lifecycle, privileged access, and mixed device fleets.

👉 Read Yubico's analysis of the DoD MFA memo and approved passkeys


Context

The core issue here is not just stronger authentication, but how identity policy catches up when a platform standardizes phishing-resistant access for constrained environments. In DoD terms, the memo reduces ambiguity around where device-bound FIDO2 passkeys and PKI-backed credentials can be used, which matters because governance breaks down when the approved method depends on interpretation rather than explicit policy.

For identity teams, the practical question is how to map device-bound passkeys, PKI credentials, and privileged access into a single lifecycle model across shared government devices, BYO mobile devices, and workstations. That is an IAM and PAM governance problem first, and an authentication-format problem second.

The broader takeaway is that policy clarity can accelerate passwordless adoption, but only if the organisation can define primary credential, device binding, and recovery paths without creating exceptions that outlive the original use case.


Key questions

Q: How should security teams roll out passkeys without creating support problems?

A: Start with recovery design, user communication, and help desk readiness. Passkeys usually fail at adoption when teams skip operational planning and treat the rollout as a simple login change. Define re-enrolment, backup authentication, and revocation steps before expansion, then stage deployment by user group and risk level.

Q: Why do strong authenticators still need identity governance?

A: Strong authenticators reduce one class of attack, but they do not manage registration, device replacement, help desk recovery, or exception handling. Those are governance tasks, not protocol features. If organisations treat the authenticator as self-sufficient, the weakest point moves to onboarding and recovery rather than to password theft.

Q: What breaks when passwordless access is added to privileged workflows without a lifecycle model?

A: Issuance, revocation, and fallback handling become inconsistent, especially when one device holds multiple credentials and one user may move across shared, personal, and privileged contexts. That inconsistency creates support gaps and can leave elevated access active longer than intended.

Q: Who is accountable when device-bound passkeys are used across shared and personal devices?

A: Accountability should sit with the identity and access governance function, because the real issue is not the hardware token alone but the policy that defines where it is valid, who approves it, and how it is recovered. That model should be reviewed alongside privileged access and certificate governance.


Technical breakdown

Device-bound FIDO2 passkeys and why binding matters

Device-bound FIDO2 passkeys tie the authenticator to a specific hardware device, which reduces replay and phishing risk because the credential cannot be casually copied into another context. In government and regulated environments, that matters because the control is not just the cryptographic ceremony, but the assurance that the key and the device remain coupled throughout use. The memo’s significance is that it turns a technical property into an approved operating model for specific DoD use cases, especially where passwordless access must still be supportable at scale.

Practical implication: treat device binding as a governance attribute, not just an authentication feature, when approving acceptable authenticators.

DoD PKI versus CAC: primary credential clarity

The memo’s clarification that DoD PKI is the primary credential resolves a policy ambiguity that can affect authorizing-official decisions and implementation scope. When an organisation is unclear about which credential is primary, it becomes hard to define fallback handling, certificate provisioning, or assurance equivalency. This is especially important when one authenticator can carry both PKI and FIDO2 credentials, because the security model depends on which credential is treated as authoritative for a given use case.

Practical implication: align identity governance, certificate policy, and helpdesk workflows to one primary-credential model before expanding passwordless use.

Shared devices, BYO mobile, and privileged access require distinct control paths

The memo distinguishes among shared government mobile devices, personal mobile devices, and IT privileged users because each introduces different trust, ownership, and recovery assumptions. A shared device can be managed centrally, a BYO phone cannot receive credentials in the same way, and privileged users need stronger controls around issuance and revocation. That variation is why a single authentication standard does not eliminate governance complexity. It changes where the controls must sit.

Practical implication: segment authentication policy by device ownership and privilege level rather than applying one passkey rule across the estate.


Threat narrative

Attacker objective: The attacker seeks durable access to sensitive systems by exploiting authentication methods that can be stolen, replayed, or socially engineered.

  1. Entry begins with phishing or credential theft against users who still rely on reusable credentials or poorly governed authentication methods.
  2. Escalation occurs when attackers reuse stolen credentials across shared devices, remote access paths, or privileged workflows with weak device assurance.
  3. Impact is unauthorized access to sensitive government or enterprise systems, with the blast radius amplified when password-based or non-device-bound authentication remains in place.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Policy clarity is now part of authentication security. The memo matters because it converts device-bound FIDO2 passkeys from a general security concept into an explicit authorised path for defined DoD scenarios. That removes one of the most common governance blockers, which is uncertainty about whether a given method is actually approved for the intended use case. For practitioners, the lesson is that authentication modernisation fails when policy language lags the control it is supposed to govern.

Primary-credential ambiguity is a governance defect, not a documentation nuisance. When a programme cannot state whether PKI, CAC, or another credential is primary, lifecycle decisions become inconsistent across issuance, revocation, and support. That inconsistency creates risk in mixed environments where one authenticator carries multiple credential types. The implication is that identity teams need a single authoritative model before scaling passwordless adoption.

Device-bound authentication changes the trust boundary, not the need for governance. A YubiKey may improve resistance to phishing, but it also shifts the control question toward device ownership, recovery, and privilege scope. That is especially visible in shared-device and BYO scenarios, where the same authenticator may be allowed in one context and disallowed in another. The practitioner conclusion is that stronger authentication only reduces risk when the surrounding policy architecture is equally explicit.

Named concept: credential-context alignment. This memo is a reminder that the value of a strong authenticator depends on matching the right credential type to the right device and privilege context. If the governance model treats all strong authentication as interchangeable, exceptions will accumulate and assurance will erode. The practical takeaway is that identity programmes should classify by credential context, not by vendor brand or form factor.

Phishing resistance is becoming a baseline expectation, but exception handling will determine outcomes. The approval of FIDO2 passkeys in high-trust environments signals where the market is heading, yet most real programmes fail in the edge cases: privileged access, BYO devices, shared mobile assets, and mixed PKI estates. The organisations that succeed will be the ones that can operationalise the exception catalogue without weakening the standard. For practitioners, that means governance, not just authentication technology, will decide whether passwordless works.

From our research:

  • Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
  • 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with human IAM efforts, which is why credential governance remains a maturity gap.
  • For a practical next step, review Guide to the Secret Sprawl Challenge for the lifecycle and exposure patterns that strong authentication alone does not solve.

What this signals

Policy approval for phishing-resistant authentication is useful, but the operational bottleneck is still governance. When identity teams cannot describe primary credential, recovery, and exception handling in the same language across IAM and PAM, authentication modernisation stalls at the edges of the programme.

Credential-context alignment: the next phase of passwordless adoption will be decided by how well organisations map credential type to device ownership and privilege scope. That matters across human IAM, NHI governance, and emerging AI-assisted workflows because the control plane is increasingly contextual, not universal. For a related control model, see NIST SP 800-207 Zero Trust Architecture.

The signal for practitioners is that device-bound authenticators are becoming normal in regulated environments, but the programme still has to prove it can handle mixed estates. If you cannot govern the exceptions, the standard will not hold, even when the authenticator itself is strong.


For practitioners

  • Define the primary credential model Document whether PKI, CAC, or another credential is primary for each environment before expanding device-bound passkeys into production use.
  • Segment policy by device ownership Create separate issuance, recovery, and revocation rules for shared government devices, BYO mobile devices, and privileged workstations.
  • Map privileged access to explicit authenticator rules Require a named approval path for IT privileged users so passkey adoption does not blur into uncontrolled elevated access.
  • Review exception handling for mixed credential estates List every case where PKI and FIDO2 credentials coexist on the same key and decide which workflows are allowed, unsupported, or time-limited.

Key takeaways

  • The memo’s real significance is policy clarity, because authentication controls only work cleanly when the approved use case is explicit.
  • Mixed credential estates create governance friction, and the biggest risk is not the key itself but inconsistent lifecycle and exception handling.
  • Passwordless adoption will depend on identity teams aligning credential type, device ownership, and privileged access policy before rollout.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63BPhishing-resistant authenticators and passkeys are central to this memo.
NIST Zero Trust (SP 800-207)Section 2The memo reflects zero-trust principles for strong, context-aware access decisions.
NIST CSF 2.0PR.AC-1The post is about access control policy and authorised authentication methods.
NIST SP 800-53 Rev 5IA-5Authenticator management and lifecycle are directly implicated by passkey and PKI use.
ISO/IEC 27001:2022A.5.15Access control policy must define which authenticators are allowed in each context.

Update access control policy so approved authenticators match device ownership and privilege level.


Key terms

  • Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
  • Primary Credential: The credential an organisation treats as the authoritative basis for authentication decisions in a given environment. When programmes mix PKI, CAC, and other authenticators, naming the primary credential matters because it determines issuance, fallback, support, and revocation logic.
  • Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
  • Credential-Context Alignment: The practice of matching a credential type to the device ownership, privilege level, and use case where it will operate. This is especially important when one authenticator can hold multiple credentials, because security depends on the context rules around issuance and use, not the token alone.

What's in the full article

Yubico's full post covers the operational detail this post intentionally leaves for the source:

  • The specific DoD use cases where device-bound FIDO2 passkeys are authorised.
  • The credential combinations supported on a single YubiKey for PKI and FIDO2.
  • The practical distinctions between shared government devices, BYO mobile devices, and privileged users.
  • The memo language around DoD PKI, CAC examples, and the 2019 mobile PKI requirements.

👉 Yubico's full post covers the DoD use cases, credential clarifications, and device form factors in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org