Every Agent Is a Login: FIDO2, Passkeys, and the Human-Facing Identity Boundary
- Topic: FIDO2, passkeys, and phishing-resistant authentication at the human-to-agent boundary; human-to-agent authorisation architecture; TEE extension; IPP 3A accountability chain
- Series: EA Thursday (Zero Trust Architecture for the Agentic Enterprise)
- Chapter: 18
- NTP claim scan: 18 e-type claims (16 sourced with project knowledge; 2 flagged as Likely confidence requiring verification: Okta 88%/22%, FIDO Alliance working group status). 6 n-type claims: 4 strict consequence (delegation architecture, FIDO2 verifier-impersonation-resistance definition, SVID credential lifetime, compromised originating session carries compromised authority), 2 lax consequence (FIDO2 session correlation enables IPP 3A accountability; re-authentication limits blast radius -- both qualified as "enables" and "limits" not "guarantees" or "eliminates" throughout)
- Defence angle paragraph (Section 27): present, 130 words, opposition test passed, reasonable observer test passed. Series defence angle cut: defence-grade identity architecture (PIV, CAC, DoD PIV standards as the architectural precedent that FIDO2 applies at the agent boundary). Per-series calibration applied: NATURAL FIT (written straight, no visible bridging effort).
[NAVIGATION LINKS: Previous: Chapter 17 | When Five Governments Tell You to Slow Down: SPIFFE, SVIDs, and Cryptographic Agent Trust | Next: Chapter 19 | OAuth 2.1 Delegation: What Your Agents Are Allowed to Do]
Last Tuesday, Okta published its AI Agents at Work 2026 research. Eighty-eight per cent of organisations reported at least one AI agent security incident in the past year. In 22 per cent of those incidents, an identity-bearing agent was involved: an agent that had been issued credentials, that held a named identity, and that became part of an attack chain precisely because that identity was in play.
Three days earlier, Cisco closed its acquisition of Astrix Security. Astrix scans agent credentials for exposure and visibility gaps. In January, CrowdStrike acquired SGNL, a just-in-time agent permissions platform. In February, Palo Alto Networks closed its acquisition of CyberArk's privileged access management capabilities. Three acquisitions across three of the five largest enterprise security platform vendors, in four months. Enterprise security vendors do not deploy acquisition capital in anticipation of incidents that have not yet happened. They deploy it after incidents are being reported at scale.
The Okta data and the acquisition wave are two readings of the same underlying signal. Agent identity is not an architectural consideration for the medium term. It is an operational problem being managed today, imperfectly, by organisations that deployed agents before the authentication architecture existed to govern them.
Chapter 17 established SPIFFE and SPIRE as the framework for non-human workload identity: how agents prove to other systems who they are. This chapter addresses the orthogonal problem. When a human authorises an agent to act, what does that authorisation look like? How is it anchored? What happens to the entire downstream agent action chain when the human-to-agent boundary is not cryptographically sound?
The answer runs through FIDO2, passkeys, and a trust architecture that was built for one problem and must be carefully extended to serve another.
What FIDO2 Actually Does
FIDO2 is a set of two specifications: WebAuthn (a W3C standard governing the browser-to-server authentication exchange) and CTAP2 (the Client to Authenticator Protocol governing the browser-to-hardware-device exchange). Together they define phishing-resistant authentication: authentication that cannot be intercepted and replayed by an adversary positioned between the user and the legitimate service.
The cryptographic mechanism is verifier impersonation resistance. When a FIDO2 credential is generated, it is mathematically bound to the relying party domain: the specific domain name of the legitimate service. The browser includes that domain in the authentication ceremony. The private key, held in hardware, signs a challenge that includes the domain. An adversary running a convincing phishing site cannot intercept a FIDO2 response and replay it against the real service, because the response was computed against the phishing domain, not the real one. The maths will not validate.
This is why NZISM v3.9, which renamed Chapter 16 to "Authentication and Access Controls" to signal this shift, introduced phishing-resistant multi-factor authentication as a control requirement. Chapter 7 of this series covered the NZISM v3.9 changes in full. The relevant point here is that NIST SP 800-63-4, which NZISM v3.9 explicitly aligns with, defines two phishing-resistant implementations: FIDO2 and PKI certificate-based authentication. Kordia's 2026 NZ Business Cyber Security Report found a 54 per cent click-through rate for AI-generated phishing compared to 12 per cent for traditional phishing. That four-and-a-half times multiplier is the empirical case for why phishing-resistant controls are now the minimum, not an aspiration.
Passkeys are the consumer and enterprise-managed device implementation of FIDO2. A passkey is a device-bound FIDO2 credential: a public-private keypair where the private key never leaves the device, unlocked by a local biometric or PIN rather than a memorised password. The credential cannot be extracted, phished, or credential-stuffed. It can only be exercised from the device to which it is bound, by the person whose biometric or PIN unlocks it.
NIST SP 800-63-4 distinguishes between synced passkeys and device-bound passkeys at the assurance level. Synced passkeys, including Apple Passwords sync and Google Password Manager sync, do not qualify for AAL3. Device-bound passkeys and hardware security keys, the YubiKey class of FIDO2 authenticator, qualify for AAL3. For privileged access in NZISM-governed environments, the cloud-sync version is not sufficient; the hardware-anchored credential is the standard.
None of this applies directly to AI agents. Agents do not have biometrics. They cannot hold a hardware security key. They cannot complete a FIDO2 ceremony. Chapter 7 noted this gap: agents cannot enrol in FIDO2; the passwordless path for human users requires a parallel path for non-human identities. That parallel path is what Chapter 17 provided, with SPIFFE and SPIRE.
This chapter sits at the boundary where the two paths meet.
The Human-to-Agent Boundary
Every agent action chain has an origin. Somewhere in that chain, a human authorised something: a task, a delegation, a workflow. The human may not have authorised every subsequent action. In a multi-agent pipeline, the initiating human may be several steps upstream from the agent that took the consequential action. But the authorisation chain began with a human interaction.
That originating interaction is the human-to-agent boundary. It is the point at which the human's authenticated identity, their FIDO2 credential, their passkey, their verified digital identity, becomes the anchor for everything that follows. If that boundary is not cryptographically sound, then the entire downstream chain, including all the SPIFFE SVID issuance and SPIRE attestation that Chapter 17 described, is built on a foundation an attacker can reach.
Consider the attack surface. An adversary who compromises a human user's authentication to an agent orchestration system does not need to attack the agents directly. They can issue instructions that appear to come from the authenticated human, with the full permission scope of that human's authorised delegation. The agents, properly authenticated to each other via SPIFFE, will execute those instructions because the orchestration system believes the human is in the session.
This is not hypothetical. The 22 per cent Okta figure describes incidents where identity-bearing agents were involved. Identity-bearing means the agent held credentials. But credentials can be issued against a compromised human session. A compromised human session that does not use phishing-resistant authentication is one successful adversary-in-the-middle attack away from becoming a compromised agent credential chain.
FIDO2's role at the human-to-agent boundary is precisely this: it closes the originating session against adversary interception. If the human authenticates to the agent orchestration platform using a FIDO2 credential or a hardware-bound passkey, the session cannot be hijacked by an adversary-in-the-middle proxy. The delegation that flows from that session carries the human's genuine, verified intent.
This is the architectural relationship between Chapter 17 and Chapter 18. SPIFFE tells the infrastructure who the agent is. FIDO2 tells the infrastructure that the human who authorised the agent's actions genuinely made that authorisation, from the specific device to which their credential is bound, and not from an adversary's relay proxy.
Where FIDO2 Reaches Its Limits in the Agent Context
FIDO2 was designed for a specific trust model: a human being, present at a physical device, authenticating to a service through a browser or native application. The design is elegant and the security properties are strong precisely because the model is constrained.
Agent deployments strain those constraints in three ways.
The first is continuous operation without human presence. A FIDO2 session is initiated by a human gesture. Once the session is established, FIDO2's protections apply to that session. But an agent may operate for hours or days without a human re-authentication event. The session, even if FIDO2-initiated, eventually requires re-establishment or long-lived token derivatives that are not themselves hardware-anchored.
The mitigation is not to extend the session indefinitely but to require re-authentication for high-consequence delegations. An agent authorised to read and summarise documents might operate on a long-lived token. An agent authorised to initiate payments, send external communications, or modify access controls should require a fresh FIDO2 ceremony for each action class. Chapter 19 on OAuth 2.1 delegation develops the scoping architecture for this pattern; FIDO2 is the authentication anchor at each re-authorisation event.
The second strain is non-human principals in the orchestration chain. When an agent delegates to a sub-agent, the delegating principal is not human. FIDO2 does not apply to agent-to-agent authentication; that is SPIFFE's domain. The boundary question becomes: how far downstream does the human's FIDO2 anchor remain traceable?
The Five Country Council "Careful Adoption of Agentic AI Services" guidance, published 1 May 2026 and co-authored by NCSC NZ, identifies accountability as a Tier 1 governance concern. Accountability requires that every agent action in a chain can be traced to an authorising human principal. FIDO2 at the origin plus SPIFFE SVIDs at each subsequent node provides the technical chain. The human FIDO2 session identifier should be propagated as a correlation identifier throughout the agent workflow log, so that any sub-agent action can be traced back to the originating authenticated session. This is a logging and correlation requirement, not a cryptographic one; but it depends on the FIDO2 session being sound at the origin.
The third strain is the absence of a finalised FIDO2 specification for agent principals. The FIDO Alliance's device attestation specifications are mature and finalised for human users. An extension addressing agentic principals, specifically how attestation applies when the authenticating entity is a software process rather than a human with hardware, has not been finalised as at June 2026. Architects deploying agent authentication now are working ahead of the standard. This is acknowledged throughout this chapter and in Section 7 of the handoff.
The Trusted Execution Environment Extension
If FIDO2's security property is that the private key is bound to a device that cannot be remotely compromised without physical access, the analogous property for an agent is that the agent's identity credential is bound to a Trusted Execution Environment that cannot be compromised by an attacker operating outside the TEE boundary.
A TEE, implemented through ARM TrustZone, Intel SGX, or AMD SEV, provides hardware-enforced isolation for a computation. Code and data within the TEE cannot be accessed or modified by the host operating system, hypervisor, or other processes running on the same machine. The TEE is the analogue of the FIDO2 hardware key: not a physical device the agent holds, but an execution environment whose integrity properties are attested by hardware rather than claimed by software.
Extending FIDO2 attestation to agent issuance events means: before an agent is issued a credential, the issuance event should include an attestation that the agent is running within a TEE whose integrity has been verified. The credential is then bound not to a physical device but to an attestation that the issuing environment meets the integrity standard. All three major cloud providers offer TEE-capable compute. The missing piece is the integration standard connecting TEE attestation to FIDO2-style credential issuance for agent principals. That is the gap the FIDO Alliance working group addresses.
For architects who cannot wait for that standard, the practical interim approach is a layered architecture: FIDO2 phishing-resistant authentication at the human-to-agent boundary, SPIFFE SVIDs for agent-to-agent authentication, and TEE-anchored credential issuance for agents in the highest-sensitivity deployment contexts. The three layers address different threat vectors and are not redundant.
The IPP 3A Connection: Identity Determines Accountability
New Zealand's Privacy Act 2020, amended by the Privacy Amendment Act 2025 and effective from 1 May 2026, introduced an explanation obligation for automated decisions. An AI agent that accesses a third-party data source, aggregates information from multiple repositories, or infers personal characteristics from non-personal data creates a legal accountability obligation.
The connection to agent authentication is direct and legally consequential. The explanation obligation, the requirement to provide an explanation of an automated decision on request, can only be discharged if the decision-maker can be identified. If the agent that made the decision cannot be cryptographically attributed to the human principal who authorised its operation, the chain of accountability is broken at the identity layer.
This is not a compliance observation for future consideration. The amendment is operative now. An organisation that has deployed agents handling personal information decisions, and that cannot demonstrate which specific agent made which decision, on behalf of which human principal, from an authenticated session that was not subject to adversary interception, has a privacy compliance exposure that FIDO2 at the human-to-agent boundary directly addresses.
The FIDO2 session identifier, propagated through the agent workflow as a correlation identifier, becomes the linchpin of that accountability chain. The human who initiated the session is identified by their FIDO2 credential. The agents that operated within that session are identified by their SPIFFE SVIDs. The delegation chain from human to agent to decision is traceable, immutable, and tied to a cryptographic authentication event that cannot be spoofed by an adversary-in-the-middle.
For NZ practitioners in the public sector: NZISM v3.9 Section 16.1 establishes the human authentication baseline. The Five Country Council guidance identifies agent accountability as a Tier 1 concern. The Privacy Amendment Act 2025 creates a legal accountability requirement that depends on agent identity being traceable. The three frameworks converge on the same architectural requirement. FIDO2 at the human boundary is not one option among several; it is the authentication standard the convergent requirement points to.
Implementation Pattern: FIDO2-Anchored Agent Authorisation
The following configuration sketch describes the authentication and authorisation flow for a FIDO2-anchored agent deployment. It is structured around a WebAuthn-capable identity provider (Entra ID, Okta Workforce Identity, or equivalent) with SPIFFE and SPIRE for agent-layer identity.
# FIDO2-Anchored Agent Authorisation Architecture# Reference: NZISM v3.9 Section 16.1; Five Country Council guidance (1 May 2026)# Identity Provider: WebAuthn RP (Relying Party) configurationwebauthn_relying_party:rp_id: "agents.agency.govt.nz"rp_name: "Agency Agent Orchestration Platform"origin: "https://agents.agency.govt.nz"authenticator_requirements:# AAL3: hardware-bound, non-exportable key required for privileged agent delegation# AAL2: passkeys (device-bound) acceptable for standard agent taskingprivileged_delegation:authenticator_attachment: "cross-platform" # hardware key, not platform authenticatorresident_key: "required"user_verification: "required"attestation: "direct" # require attestation statementkey_type: "hardware_bound"key_exportable: falsestandard_delegation:authenticator_attachment: "platform" # device-bound passkey acceptableresident_key: "preferred"user_verification: "required"attestation: "indirect"# Session correlation for agent workflow audit trail (accountability chain)session_correlation:session_id_propagation: truecorrelation_header: "X-Agent-Auth-Session"# Session ID must be propagated to all child agent SPIFFE SVID issuance events# Agent delegation scoping (see Chapter 19: OAuth 2.1 Delegation for full treatment)delegation_scopes:high_consequence_actions:- "payment.initiate"- "communication.external"- "access.modify"- "data.export"re_authentication_required: true # fresh FIDO2 ceremony per action classsession_lifetime_seconds: 0 # no cached authorisation for these scopesstandard_actions:- "document.read"- "document.summarise"- "calendar.query"session_lifetime_seconds: 3600 # one-hour cached delegation acceptable# Audit logging (NZISM v3.9 Section 16.7; accountability chain)audit:log_fido2_ceremony: truelog_delegation_scope: truelog_session_correlation_id: truelog_agent_spiffe_id: truetamper_evident: trueretention_days: 2555 # seven years; standard NZ records obligationThe critical design decision is the session correlation header. The FIDO2 authentication event produces a session identifier. That identifier must be threaded through every subsequent agent action in the workflow as a correlation reference. When an agent operating three steps downstream in a pipeline takes a consequential action, the audit record must contain the FIDO2 session identifier of the human who initiated the chain. Without this correlation, accountability attribution is not possible at the individual agent action level.
The re-authentication requirement for high-consequence actions is the second critical design decision. It limits the blast radius of any compromised session: an attacker who manages to impersonate a human session can issue standard tasks to agents but will be challenged for a fresh FIDO2 ceremony before any action in the high-consequence scope can be delegated. The ceremony cannot be completed without the human's hardware device, defeating the impersonation.
An Honest Assessment of the Attestation Gap
The architecture described in the preceding section is sound in its principles and achievable with current tooling for the human-facing components. The TEE-anchored agent credential issuance extension is where honest assessment requires qualification.
No finalised FIDO2 specification governs attestation for agent principals as at June 2026. The FIDO Alliance working group activity on this topic is in progress, not resolved. Architects who need to deploy agent authentication now are building on the mature human-facing components of FIDO2, using SPIFFE for agent-layer identity, and waiting for the agent attestation standard to catch up.
This is not a reason to defer deployment. The human-to-agent boundary is where the standard is mature and the protection is real. The TEE extension addresses a narrower, more sophisticated attack surface that most enterprise deployments will not face in the near term. The CrowdStrike and SGNL zero-standing-privilege model, which issues agent credentials scoped to specific tasks and revokes them immediately on completion, provides a pragmatic interim approach: not TEE attestation at issuance, but minimal credential lifetime and maximum revocation speed, which reduces the window within which a compromised agent credential can do harm.
The architectural sequence is: FIDO2 at the human boundary now, SPIFFE SVIDs for agent-to-agent authentication now, and TEE-anchored credential issuance as the standard matures. Deploy in that order and you have addressed the documented attack vectors. The Okta 22 per cent incident rate is not primarily driven by sophisticated TEE-bypass attacks; it is driven by the basic absence of identity governance at the agent layer. The foundational architecture closes the documented gap.
What the Market Has Decided
The three acquisitions, Cisco and Astrix, Palo Alto Networks and CyberArk, and CrowdStrike and SGNL, represent a convergent market verdict. Each acquisition targets a different layer of the agent identity problem: credential scanning and visibility (Astrix), privileged access management for agentic environments (CyberArk's capabilities), and just-in-time credential issuance with zero-standing-privilege architecture (SGNL).
None of these acquisitions addresses the human-to-agent boundary directly. They address the agent-layer and the credentials-in-flight problem. This is a market gap that FIDO2 practitioners can speak to clearly: the credential management of agents matters, but so does the authentication quality of the human at the origin of the delegation chain. A credential scanner that finds every exposed agent API key in your environment is not a substitute for a FIDO2-anchored originating session.
The Microsoft 2026 Work Trend Index finding that 26 per cent of leadership teams are aligned on AI governance is relevant context here. If 74 per cent of leadership teams are not aligned on AI governance, the authentication standard at the human-to-agent boundary will be set by default, not by architecture. The default is whatever the identity provider ships as its out-of-the-box configuration for agent orchestration platforms. That configuration is rarely FIDO2-mandated for the agent delegation scope specifically.
The practitioner's job is to specify that requirement explicitly before the agents are deployed. Not after. The Okta data confirms that after is too late for a substantial proportion of the 88 per cent.
For NZ Architects: The Practical Sequence
The Five Country Council guidance, NZISM v3.9, and the Privacy Amendment Act 2025 together create a clear sequence for NZ public sector architects deploying agent systems in 2026.
First, confirm that your agent orchestration platform's human-facing authentication uses FIDO2 or hardware-bound passkeys. Agents with access to personal information, financial systems, or administrative functions qualify as privileged contexts. Standard push-notification multi-factor authentication does not meet the phishing-resistant requirement for these delegation contexts.
Second, configure session correlation. The FIDO2 session identifier must propagate through your agent workflow audit trail. Without it, a compliance audit or a privacy inquiry asking "which agent made this decision, on whose authority?" cannot be answered from the logs.
Third, scope delegations explicitly. High-consequence actions should require re-authentication per the configuration pattern above. Standard actions may operate on session-scoped delegation. The scope boundary should be documented and reviewed as part of your agent lifecycle governance.
Fourth, plan for the agent attestation standard. When it arrives, it will require that your agent issuance infrastructure can consume TEE attestation. Planning for that integration now, even before the standard is finalised, reduces the retrofit cost.
NZISM v3.9 does not yet include specific controls for agent credential authentication. The Five Country Council guidance identifies the Tier 1 concern but does not prescribe the specific authentication standard for the human-to-agent boundary. The convergence of NIST SP 800-63-4 requirements, the FIDO2 phishing-resistant mandate in NZISM v3.9 for human access, and the accountability requirements in the Privacy Amendment Act 2025 and the Five Country Council guidance points to FIDO2 as the appropriate standard. NZ architects should apply it at the human-to-agent boundary without waiting for a specific NZISM control to mandate it.
Connecting Frameworks
Chapter 16 diagnosed the non-human identity challenge. Chapter 17 provided the workload identity resolution with SPIFFE and SPIRE. This chapter addresses the human-side anchor that makes the full identity architecture coherent. Chapter 19 on OAuth 2.1 delegation addresses the authorisation scope: once the human is authenticated and the agent is identified, what is the agent permitted to do? Chapter 20 on Chain of Agency addresses the multi-step pipeline: when authenticated agents delegate to other authenticated agents, how does the trust chain remain coherent across the full execution arc?
The Lethal Trifecta, introduced in Chapter 5, describes the three-capability combination that creates structural insider threat conditions: access to sensitive data, exposure to untrusted content, and the ability to communicate or execute externally. The second element of the Trifecta, persistent credentials, is the specific attack surface that FIDO2 addresses at the human boundary and SPIFFE addresses at the agent layer. A human session that requires re-authentication per the configuration pattern above does not carry persistent credentials across high-consequence delegation scopes. The credential lifetime matches the action scope.
What This Means for Defence-Grade Identity Architecture
The principle FIDO2 applies at the human-to-agent boundary is not new to the defence and intelligence community. The US Department of Defense's Personal Identity Verification (PIV) and Common Access Card (CAC) standards embed the same requirement: cryptographic authentication per transaction, not implicit trust from a prior authenticated session. PIV credentials, governed by NIST SP 800-73 and implemented across US federal agencies and allied access contexts, are hardware-anchored, phishing-resistant, and bound to a specific physical card that cannot be replicated. The CAC is the DoD-specific implementation: two million active cards carrying credentials that gate access to classified networks, weapons systems management, and logistics chains. Both standards treat authentication as a per-access event, not a per-session assumption.
FIDO2 at the human-to-agent boundary applies that same per-transaction discipline to civilian and public sector agent orchestration. An NZ public sector architect deploying agent systems in health, social housing, or justice contexts is not dealing with classified networks, but the accountability requirements are analogous: every consequential agent action must be traceable to a verified human principal through a credential that cannot be intercepted. The PIV and CAC standards proved that hardware-anchored, per-transaction identity is operationally sustainable at scale. FIDO2 delivers the same architecture for the environments where PIV and CAC do not reach, including the agent orchestration platforms being deployed across the NZ public sector today.
What would your organisation's answer be to this question: if one of your AI agents made a consequential automated decision last Tuesday, could you identify the human whose FIDO2-authenticated session initiated the delegation chain, trace every agent action that followed from it, and demonstrate that no adversary was positioned between the human and the originating session? If that answer requires more than a registry query and a log search, the architecture described in this chapter is the gap you are filling.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture and Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] Okta. "AI Agents at Work 2026." 3 June 2026. okta.com (specific report URL to be confirmed)
[2] Cisco. "Cisco Completes Acquisition of Astrix Security." 4 May 2026. cisco.com
[3] CrowdStrike. "CrowdStrike Acquires SGNL." January 2026. crowdstrike.com
[4] Palo Alto Networks. "Palo Alto Networks Completes Acquisition of CyberArk Privileged Access Management Capabilities." February 2026. paloaltonetworks.com
[5] NCSC NZ. "New Zealand Information Security Manual v3.9." 9 May 2025. nzism.gcsb.govt.nz
[6] NIST. "SP 800-63-4: Digital Identity Guidelines." July 2025. pages.nist.gov/800-63-4/
[7] Kordia. "2026 NZ Business Cyber Security Report." March 2026. Kordia press release.
[8] CISA / NCSC NZ et al. "Careful Adoption of Agentic AI Services." 1 May 2026. cisa.gov (specific URL to be confirmed)
[9] New Zealand Parliament. "Privacy Amendment Act 2025." Royal Assent 23 September 2025. legislation.govt.nz
[10] Office of the Privacy Commissioner. Privacy Act 2020 guidance. privacy.org.nz
[11] W3C. "Web Authentication: An API for accessing Public Key Credentials Level 2." w3.org/TR/webauthn
[12] FIDO Alliance. "FIDO2 Specification Overview." fidoalliance.org
[13] Microsoft. "2026 Work Trend Index." microsoft.com
[14] NIST. "SP 800-73: Interfaces for Personal Identity Verification." csrc.nist.gov/publications/detail/sp/800-73/4/final