Anthropic Adds Identity Verification for Claude Access

A researcher running Claude for document analysis last month hit an unexpected wall: a verification prompt mid-session, no warning in advance, no clear path to resume work. The session was gone. The workflow was gone. Whatever Anthropic's reasons for the change, the user experience of encountering it unannounced is not a smooth one, and the Hacker News thread that followed the announcement made clear this was not an isolated incident.

Anthropic has introduced identity verification requirements for Claude access. The support page is spare on detail: verification is required in some circumstances, phone numbers or government ID may be requested, and failure to complete it can restrict access. What the page does not say is how Anthropic decides when to trigger the requirement, what data is retained after verification, or what happens to API sessions mid-flight when a linked account gets flagged.

What this costs you: time, friction, and trust

Identity verification sounds trivial until you map out who actually uses Claude and in what context. A solo developer building on the Claude API has a different exposure than a team sharing a workspace account, and both are different from a user accessing Claude.ai through a browser with no organizational affiliation.

The direct costs break down like this:

• Time to verify: Phone verification takes under a minute. Government ID verification, if required, typically takes 3 to 15 minutes including document upload and review lag. That is per account, not per user on a shared plan.
• Interruption cost: If verification is triggered mid-session rather than at signup, any unsaved context is lost. For long-context document workflows, that can represent 20 to 40 minutes of setup work.
• Privacy friction: Some users, particularly in Europe, will push back on submitting government ID to a US-based AI company. The legal questions around data retention are not nothing, and Anthropic's support page does not address them.
• Team onboarding: Organizations provisioning Claude access for 10 or 50 employees now have an additional step per person that may or may not be compatible with SSO or centralized account management.
• Migration risk: Teams that hit verification as a surprise mid-project have immediate incentive to look at alternatives. That evaluation process costs time even if they return to Claude.

There is no published pricing impact - verification does not appear to change subscription tiers. But access restriction as a consequence of failed or declined verification is effectively a capability cost, which matters more for power users than casual ones.

Why Anthropic did this, and why the timing is significant

The headline reads as a policy change. The mechanism underneath it is a liability calculation.

Anthropic is operating in a regulatory environment that is moving fast. The EU AI Act has started imposing compliance obligations. US policymakers have been vocal about AI systems being used to generate harmful content, run coordinated inauthentic behavior, or produce CSAM. Every major AI lab has faced public scrutiny on at least one of these fronts in the last eighteen months. Identity verification is a documented, auditable control that lets Anthropic say to regulators: we know who is using the system, we can trace abuse back to an account, and we can revoke access.

That is not cynical. It is rational. The problem is that the logic of compliance does not map cleanly onto the logic of user experience. A legitimate researcher who uses Claude anonymously because they are studying a sensitive topic - extremism, self-harm interventions, legal gray areas - gets caught in the same net as a bad actor. The verification requirement does not distinguish between them. It just establishes that a real identity exists behind the account, which satisfies an audit requirement without necessarily improving safety outcomes at the model level.

The timing matters too. Anthropic is pushing Claude into enterprise contexts aggressively. Claude Connectors and the broader API ecosystem assume organizational trust structures. Identity verification at the account level is the foundation you need before you can offer things like audit logs, role-based access controls, and compliance certifications. This change is not just about abuse prevention. It is infrastructure for the enterprise product Anthropic is building toward.

A specific scenario: the independent consultant on a Free plan

Consider a freelance UX researcher who has been using Claude.ai on the free tier for six months. Her workflow: paste in interview transcripts, ask Claude to identify themes, export the summary to a client report. She uses a personal email, no phone number on file, no organizational affiliation.

Under the new policy, here is what her experience looks like:

1. She opens a session with a 12,000-word transcript from a client project.
2. Mid-analysis, or at next login, she encounters a verification prompt.
3. She is asked to provide a phone number. She uses a secondary number she does not regularly check.
4. The SMS code arrives. She enters it. Access resumes.
5. Three weeks later, she switches phones. The old number is gone. Her account is now in a gray area.

This is a realistic failure path, not a hypothetical edge case. Phone numbers are not stable identifiers. People change carriers, use VoIP numbers, work across multiple countries. The friction here is not the initial verification - it is the maintenance of that verification over time. Anthropic's support page does not describe what happens when a verified identifier becomes invalid.

For this user, the practical question becomes whether the free tier is worth the overhead. If she is already doing client work with Claude, a paid plan with clearer account controls might be worth $20 per month. Or she evaluates Claude against Gemini, which currently has no equivalent public verification requirement, and decides the workflow difference is small enough to switch.

How Claude, ChatGPT, and Gemini compare on access friction

Platform	Signup requirement	Identity verification	API access friction	Account suspension risk
Claude (Anthropic)	Email required	Phone or ID, conditions unspecified	Credit card for paid API	Mid-session possible if triggered
ChatGPT (OpenAI)	Email required	Phone for some features (e.g. voice)	Credit card for API	Account-level, not mid-session
Gemini (Google)	Google account	Tied to existing Google identity	GCP billing account	Google account-level policies apply

Gemini's approach is worth noting: Google already has identity verification baked into account creation, so there is no separate step. The downside is that you are handing Google a much deeper identity profile than a one-time phone verification. ChatGPT's verification is feature-gated rather than access-gated, which is a meaningfully different design choice - it adds friction to specific capabilities rather than to baseline access.

If you are a solo user on a free plan who hit this requirement unexpectedly, the least painful path is completing phone verification and noting that government ID can likely be avoided unless Anthropic escalates the requirement for your account type.

If you are managing team access, this is a signal to get ahead of it: audit which accounts lack verified identifiers before the requirement propagates to your tier, and check whether your organizational account management setup handles this gracefully.

If your primary concern is privacy, Gemini's model does not actually reduce your data exposure compared to a one-time phone check - it expands it. The most privacy-conscious option in this comparison is still Claude with a separate phone number used only for verification purposes.

The question that actually matters here, and that Anthropic has not answered publicly: at what account behavior threshold does identity verification get triggered, and is that threshold static or adaptive? If it is adaptive - tuned by usage patterns, content flags, or geographic signals - then the policy is functionally opaque, and users have no way to know whether their legitimate use case puts them at risk of a verification demand. That opacity is a harder problem than the verification step itself.