OpenAI’s Advanced Account Security Seals the Support-Led Door

AAS changes the authentication stack. It disables password logins, requires passkeys or hardware security keys, and explicitly disables email/SMS recovery while instructing Support not to perform recovery for enrolled accounts. (openai.com) Account recovery flows are the canonical backdoor. When recovery relies on email or SMS, attackers exploit weaker upstream systems: SIM swaps, compromised email accounts, or coerced call-center staff. Those attacks scale cheaply and sidestep modern cryptography. By removing those routes, AAS forces attackers into possession-based attacks: steal the private key or compromise the device holding the passkey. OpenAI frames this as a responsibility shift—stronger protection in exchange for users managing recovery. The design follows the same logic as enterprise protection tiers like Google’s Advanced Protection and signals that OpenAI expects AAS to serve as a control for high-risk accounts. (axios.com)

Support-led takeovers are a persuasion chain. An attacker harvests public signals (name, email, device hints), exploits carrier or provider verification weaknesses, then convinces a human operator to reassign a number or reset credentials. One successful call or ticket can bypass passwords and SMS-based MFA. The trust boundary is the support operator’s decision. Attackers substitute effort in persuasion for the far higher effort of breaking cryptography. That asymmetry makes support-led attacks cheap and scalable, as seen in SIM-swap incidents and corporate social-media takeovers. (krebsonsecurity.com) OpenAI addresses this asymmetry directly by removing human-operated recovery channels for AAS users. That narrows the attack surface to possession of private credentials, something purely technical defenses like shorter sessions cannot achieve alone. (openai.com)

Passkeys and hardware security keys convert authentication into proof-of-possession. A private credential stays on the device; FIDO2/WebAuthn verifies possession without transmitting secrets. That built-in phishing resistance is why hardware keys are the canonical control against social-engineered takeovers. (openai.com) The practical consequence is sharper: attackers must steal a physical key or fully compromise the device that holds a passkey. Those operations are more expensive, riskier, and harder to automate than calling Support or porting a SIM. OpenAI’s Yubico partnership signals a push to lower adoption friction so protection actually gets used. (markets.financialcontent.com) Cryptography is not a cure-all. Device malware, supply-chain tampering, and coerced disclosure remain real threats. Recovery schemes that rely on a single surviving key are brittle. Still, shifting the baseline attacker effort to cryptographic possession changes attacker ROI and forces higher-effort, targeted campaigns instead of mass support-fraud and phishing.

Removing Support-assisted recovery imposes a real operational cost. If users lose keys or backup passkeys, they can permanently lose access to their accounts and data. OpenAI requires backup passkeys, hardware keys, or recovery keys and warns users they are responsible for recovery. (openai.com) Mitigations are procedural and engineering tasks. Individuals should register at least two hardware keys, keep an encrypted offline recovery key in a safe, and enroll a secondary passkey on a separate device. Enterprises should pair phishing-resistant auth with SSO and enforce hardware-token escrow for admins. OpenAI’s policy that Trusted Access for Cyber members must enable AAS (or attest to equivalent SSO protections) by June 1 shows the hybrid approach: mandate controls for high-risk actors, leave general users an opt-in path. The defender’s problem now shifts from preventing phone-call fraud to building robust offboarding, key rotation, and lost-key recovery processes. Those are solvable engineering problems but require discipline and resources to operationalize.