OpenAI’s Hardware Passkey Mandate for Trusted Cyber Access

Key Takeaways

• Beginning September 1, 2026, individual members of OpenAI’s Trusted Access for Cyber (TAC) program must enable Advanced Account Security with a hardware-backed passkey or lose access to OpenAI’s most capable cyber-focused models, reverting instead to standard consumer access [1][2].
• The mandate targets a program built around identity-verified access to frontier models, including the newly released GPT-5.6 Sol, which OpenAI classifies as “High” capability in cybersecurity under its Preparedness Framework [3][4].
• OpenAI partnered with Yubico to offer discounted custom YubiKey hardware but will accept any FIDO2-compliant security key [2], reflecting what Yubico has characterized as a broader shift toward phishing-resistant authentication as AI systems gain the ability to act autonomously on a user’s behalf [5].
• Independent analysts have raised practical concerns about the mandate, including its incompatibility with fully automated API workflows, added procurement and support costs, and accessibility barriers for users without convenient access to hardware tokens [1].
• In CSA’s assessment, this requirement may signal a broader industry pattern of frontier AI providers layering identity proofing onto traditional credentials as model capabilities rise, though OpenAI is currently the clearest example of this approach.

Background

OpenAI introduced Trusted Access for Cyber (TAC) in February 2026 as a vetting framework intended to give legitimate security researchers, defenders, and organizations access to AI capabilities that the company otherwise restricts on ordinary accounts [6]. The program combines automated identity verification, including government ID checks and know-your-customer (KYC) screening conducted through the identity verification vendor Persona, with a tiered set of models purpose-built for defensive cybersecurity work such as vulnerability triage, malware analysis, detection engineering, and patch validation [3][6]. Early TAC tiers granted access to GPT-5.3-Codex, a frontier reasoning model engineered for extended autonomous operation on complex security workloads, and GPT-5.4-Cyber, a fine-tuned variant with fewer of the capability restrictions applied to general-purpose accounts [6][7]. OpenAI has since described its intent to scale TAC to thousands of verified individuals and hundreds of teams responsible for defending critical software, positioning the program as a way to extend advanced capabilities to legitimate defenders of all sizes, including those protecting critical infrastructure, while withholding the same capabilities from unverified or anonymous users [6].

The table below summarizes how TAC’s model tiers and their capability restrictions have evolved since the program’s February 2026 launch.

This expansion sits alongside the July 2026 release of GPT-5.6, OpenAI’s newest model family, which spans three tiers: Sol for the most demanding tasks, Terra for balanced everyday use, and Luna for high-volume, cost-sensitive applications [4]. GPT-5.6 Sol is, by OpenAI’s own account, its most capable model to date for long-horizon cybersecurity work, including vulnerability research and exploit development; on internal benchmarks the model scored 73.5% on ExploitBench 2 compared with 47.9% for its predecessor GPT-5.5, and nearly doubled peak pass rates on ExploitGym 3 under time-constrained testing [4]. OpenAI’s GPT-5.6 system card classifies all three variants — Sol, Terra, and Luna — as “High” capability in the cybersecurity category under the company’s Preparedness Framework, one step below the “Critical” threshold that would trigger the most stringent deployment restrictions, and notes that the models remain better at identifying and remediating vulnerabilities than at executing complete, autonomous attacks against hardened targets [3]. OpenAI states that safeguards for GPT-5.6 Sol block roughly ten times more potentially harmful activity than prior model generations, combining training-time alignment, activation classifiers for sensitive domains, and real-time output scanning [3].

It is against this backdrop that OpenAI announced, in the early summer of 2026, that individual TAC members would be required to enable hardware-backed passkey authentication by September 1 to retain access to frontier cyber models [1][2]. This is not OpenAI’s first move toward stronger identity assurance for advanced model access: in April 2025 the company introduced a separate “Verified Organization” program requiring government-issued ID to unlock certain advanced models and capabilities through the API, a measure OpenAI attributed at the time to a small number of developers violating usage policies [8]. The TAC hardware passkey requirement extends that trajectory from organization-level API verification to individual-level account authentication, and from software-based identity checks to cryptographic, device-bound credentials.

Security Analysis

This note characterizes the TAC hardware passkey mandate as creating a two-layer trust model: identity proofing establishes that an account belongs to a legitimate, vetted individual, while hardware-backed authentication ensures that only that individual, in physical possession of a specific device, can subsequently log in and exercise the account’s elevated privileges. Hardware-backed passkeys differ meaningfully from the software passkeys and legacy multi-factor authentication (MFA) methods, such as SMS codes or app-based one-time passwords, that they are intended to replace. Because the private key never leaves the physical authenticator and cannot be synced, copied, or remotely extracted, hardware-backed passkeys resist common account takeover techniques including phishing, credential stuffing, and adversary-in-the-middle proxy attacks that can defeat push-based or code-based MFA [1][2]. OpenAI has framed the requirement as an effort to “dramatically raise the barrier to entry” for threat actors and to disrupt the criminal ecosystem that creates, validates, and resells compromised accounts with access to premium AI capabilities [2].

Yubico, which is supplying custom hardware for the program, has articulated a broader rationale tied to the growing autonomy of AI systems themselves. Albert Biketi, Yubico’s chief product and technology officer, characterized the shift as moving away from “probabilistic” security dependent on password strength and toward hardware-backed cryptographic certainty, arguing that “we are in an era where AI can analyze vulnerabilities and act on our behalf. In that world, the only thing more powerful than the AI itself is the identity of the person controlling it” [5]. In this framing, the physical tap required to unlock a hardware key functions as a deliberate checkpoint for verified human authorization before an increasingly capable model is allowed to take high-impact action, such as executing code or interacting with production systems, on a user’s behalf [5]. OpenAI is offering two co-branded hardware options through Yubico at discounted pricing: a YubiKey C NFC intended for tap-based authentication on mobile devices, and a YubiKey C Nano designed to remain plugged into a laptop’s USB-C port, alongside support for any other FIDO2-compliant security key already in a user’s possession [2][9].

This layering matters because identity proofing and authentication address different failure modes; in this note’s assessment, the two controls function as complementary rather than redundant. The government ID and KYC screening conducted through Persona at enrollment establish that a specific real-world person, rather than an automated account farm or a sanctioned entity, is behind a given TAC membership; this proofing step happens once, or periodically, and does not by itself prevent that legitimate account from later being phished or hijacked. The hardware passkey requirement addresses that separate, ongoing risk by binding every subsequent login to possession of a specific physical device, so that even a fully successful phishing attempt against a verified TAC member cannot yield a usable credential for an attacker sitting outside that device’s physical reach. Considered together, the two controls narrow the population that can reach frontier cyber capabilities from “anyone who signs up” down to “a specific vetted person, authenticating from a specific physical key” — a stronger assurance chain than either control alone, though this note does not attempt to quantify the improvement.

The requirement is not without friction, and independent analysis has surfaced several practical concerns worth weighing against its security benefits. A Forrester analyst commentary on the mandate identified three specific issues: first, that API-based access to frontier cyber models cannot be fully automated if hardware authentication is required at the account level, creating tension between the mandate and TAC’s own use cases involving extended, unattended agentic workflows; second, that organizations adopting the requirement face real operational costs for procuring, distributing, managing, and replacing physical devices, along with building account recovery procedures for lost or damaged keys; and third, that geographic availability and general usability challenges could create accessibility barriers, effectively excluding some otherwise-qualified researchers from top-tier AI capabilities [1]. The same analysis suggested device-bound software passkeys with secure synchronization as a more practical middle ground for organizations that need hardware-equivalent phishing resistance without the logistical overhead of physical tokens [1]. These trade-offs mirror a long-standing tension in authentication design between security assurance and usability, one that CSA’s own guidance on passkey adoption has documented in the more general context of consumer and enterprise web authentication.

Recommendations

Immediate Actions

Security teams and individual researchers who hold TAC accounts should confirm their FIDO2-compliant hardware inventory now rather than waiting for the September 1 deadline, since procurement lead times for hardware security keys can extend past the compliance date if ordered late. Organizations with multiple TAC-enrolled personnel should also inventory who currently relies on TAC access for time-sensitive defensive workflows, such as active vulnerability triage or incident response, and prioritize those individuals for hardware key enrollment first.

Short-Term Mitigations

Organizations should establish account recovery procedures before enrollment, not after a key is lost, given that OpenAI’s own vetting process already requires government ID and KYC verification that would need to be repeated or supplemented in a recovery scenario. Teams should also document which workflows depend on TAC’s frontier cyber models specifically, so that any gap in hardware key availability, device failure, or delayed re-verification does not silently degrade an organization’s detection or patch-validation capacity by reverting affected accounts to standard model access without anyone noticing.

Strategic Considerations

Enterprises should treat OpenAI’s hardware passkey mandate as one vendor’s answer to identity assurance for a single frontier model provider, not as a substitute for an organization’s own access governance over how AI capabilities are provisioned, used, and audited internally. As frontier model access increasingly depends on individual accounts vetted by external providers rather than organization-managed credentials, security teams should extend existing identity and access management practices, including credential lifecycle management and least-privilege provisioning, to cover these AI accounts with the same rigor applied to other high-value systems. Organizations should also anticipate that other frontier model providers offering elevated cyber, biological, or agentic capabilities may adopt comparable hardware-authentication requirements as model capability classifications rise, and should build vendor-agnostic hardware key procurement and recovery processes now rather than standing up a bespoke process for each provider.

CSA Resource Alignment

This development connects directly to CSA’s existing guidance on passkey technology. CSA’s Beyond Passwords: The Role of Passkeys in Modern Web Security provides the technical foundation for understanding exactly what OpenAI is mandating: the paper’s threat model comparing passkeys, hardware tokens, and legacy MFA against phishing, credential stuffing, and adversary-in-the-middle attacks maps closely onto the rationale OpenAI and Yubico have offered for the TAC requirement, and its implementation guidance on device management, backup strategies, and account recovery planning is directly applicable to the recovery procedures organizations should build before enrolling TAC accounts [10].

CSA’s Confronting Shadow Access Risks: Considerations for Zero Trust and Artificial Intelligence Deployments is also highly relevant, since it addresses the broader governance question this mandate raises: accounts with elevated, individually-vetted access to AI capabilities are exactly the kind of high-privilege identity that Shadow Access guidance warns can escape an organization’s own Zero Trust controls if it is managed only through a vendor’s external verification process. That paper’s emphasis on explicit visibility and continuous verification of AI-related access reinforces this note’s strategic recommendation that organizations build their own access governance layer rather than relying solely on provider-side controls like TAC’s hardware passkey requirement [11].

Finally, organizations formalizing AI access governance programs should reference the identity and access management domain of the AI Controls Matrix (AICM) v1.1, which provides control objectives for AI-specific authentication, credential management, and access provisioning that extend naturally to managing accounts with elevated access to external frontier model providers [12].

References

[1] Forrester. “OpenAI Makes Hardware Passkeys Mandatory For Its Highest-End Cyber Model.” Forrester Blogs, 2026.

[2] Yubico. “OpenAI Mandates Hardware-Backed Passkeys for Trusted Access Cyber Members to Log Into ChatGPT Accounts.” Yubico Blog, 2026.

[3] OpenAI. “GPT-5.6 System Card.” OpenAI Deployment Safety Hub, July 2026.

[4] OpenAI. “GPT-5.6: Frontier Intelligence That Scales With Your Ambition.” OpenAI, July 9, 2026.

[5] Help Net Security. “OpenAI Requires Stronger Authentication for Users of Its Most Powerful AI Models.” Help Net Security, June 1, 2026.

[6] OpenAI. “Introducing Trusted Access for Cyber.” OpenAI, February 2026.

[7] Help Net Security. “OpenAI Expands Its Cyber Defense Program With GPT-5.4-Cyber for Vetted Researchers.” Help Net Security, April 15, 2026.

[8] Business Standard. “OpenAI Introduces ID Verification Process for Access to Upcoming AI Models.” Business Standard, April 2025.

[9] Biometric Update. “OpenAI Requires Hardware-Backed Passkeys for Trusted Cyber Access.” Biometric Update, July 2026.

[10] Cloud Security Alliance. “Beyond Passwords: The Role of Passkeys in Modern Web Security.” CSA, 2023.

[11] Cloud Security Alliance. “Confronting Shadow Access Risks: Considerations for Zero Trust and Artificial Intelligence Deployments.” CSA, 2024.

[12] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” CSA, 2026.